idnits 2.17.1 draft-bider-ssh-quic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([QUIC], [RFC4251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 July 2020) is 1385 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 351 -- Looks like a reference, but probably isn't: '32' on line 355 -- Looks like a reference, but probably isn't: '255' on line 264 -- Looks like a reference, but probably isn't: '16' on line 386 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force d. bider 3 Internet-Draft Bitvise Limited 4 Intended status: Informational 5 July 2020 5 Expires: 6 January 2021 7 QUIC-based UDP Transport for Secure Shell (SSH) 8 draft-bider-ssh-quic-00 10 Abstract 12 The Secure Shell protocol (SSH) [RFC4251] is widely used for purposes 13 including secure remote administration, file transfer using SFTP and 14 SCP, and encrypted tunneling of TCP connections. Because it is based 15 on TCP, SSH suffers similar problems as are motivating the HTTP 16 protocol to transition its transport to UDP-based QUIC [QUIC]. These 17 include: unauthenticated network intermediaries can trivially 18 disconnect SSH sessions; SSH connections are lost when mobile clients 19 change IP addresses; and performance limitations in OS-based TCP 20 stacks. This memo leverages QUIC to provide a UDP-based transport to 21 SSH sessions with full backward compatibility, after completing the 22 initial SSH key exchange. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 6 January 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 59 1.2. Wire Encoding Terminology . . . . . . . . . . . . . . . . 3 60 2. New SSH/QUIC Encryption Algorithms . . . . . . . . . . . . . 3 61 2.1. SSH/QUIC Algorithm Negotiation . . . . . . . . . . . . . 3 62 2.2. Use of SSH Compression . . . . . . . . . . . . . . . . . 5 63 2.3. Use of SSH_MSG_EXT_INFO . . . . . . . . . . . . . . . . . 6 64 3. UDP Routability Probe . . . . . . . . . . . . . . . . . . . . 6 65 3.1. UDP Probe Acknowledgment . . . . . . . . . . . . . . . . 8 66 4. Transition Using SSH_MSG_NEWKEYS . . . . . . . . . . . . . . 9 67 5. QUIC Setup . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . . . 12 69 6. SSH/QUIC Packet Format . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 THIS DOCUMENT IS AN EARLY VERSION AND IS A WORK IN PROGRESS. 81 ANY IMPLEMENTATION AT THIS STAGE IS EXPERIMENTAL. 83 CONTACT THE AUTHOR IF YOU HAVE INTENT TO IMPLEMENT. 85 This memo leverages QUIC to provide a UDP-based transport to SSH by 86 replacing QUIC's use of TLS, including its TLS handshake, with pre- 87 initialized secrets derived from the initial SSH key exchange. An 88 SSH/QUIC session begins as traditional TCP-based SSH. A QUIC 89 encryption algorithm can be negotiated opportunistically in 90 SSH_MSG_KEXINIT. If a QUIC algorithm can be negotiated, the client 91 probes the server for UDP routability while the SSH key exchange 92 takes place. Upon successful key exchange, the client uses 93 SSH_MSG_NEWKEYS to either transition to QUIC, or continue with TCP- 94 based SSH. Any QUIC connection uses the same server-side UDP port 95 number as the initial TCP connection. 97 A transition to QUIC may occur only after the initial SSH key 98 exchange. Once a transition to QUIC has occurred, no SSH key re- 99 exchange takes place. 101 This memo updates [RFC4253] to define new encryption algorithms for 102 QUIC; describe new semantics for opportunistic negotiation of 103 encryption algorithms, so the session may continue over TCP or QUIC; 104 and extend SSH_MSG_NEWKEYS to signal a transition to QUIC. 106 1.1. Requirements Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 1.2. Wire Encoding Terminology 116 The wire encoding types in this document -- "byte", "uint32", 117 "mpint", "string", "name-list" -- have meanings as described in 118 [RFC4251]. 120 2. New SSH/QUIC Encryption Algorithms 122 This memo adopts the style and conventions of [RFC4253] in specifying 123 how use of an encryption algorithm is indicated in SSH. 125 The following new encryption algorithms are defined: 127 quic:aes128-gcm-sha256 OPTIONAL TLS_AES_128_GCM_SHA256 128 quic:aes256-gcm-sha384 OPTIONAL TLS_AES_256_GCM_SHA384 129 quic:chacha20-poly1305-sha256 OPTIONAL TLS_CHACHA20_POLY1305_SHA256 130 quic:aes128-ccm-sha256 OPTIONAL TLS_AES_128_CCM_SHA256 132 Figure 1 134 2.1. SSH/QUIC Algorithm Negotiation 136 This memo reserves the use of SSH algorithm names beginning with 137 "quic:" (case sensitive) for use with opportunistic negotiation of 138 QUIC algorithms in SSH. Implementations MUST NOT use algorithm names 139 of this form except in ways compliant with this section. 141 A "quic:" prefix is used so that the format "quic:name@domain" 142 remains available for private extension. Implementations MUST treat 143 all "quic:" algorithms as described in this section, whether they are 144 known or unknown, and whether they are standard ("quic:name") or 145 private ("quic:name@domain"). 147 If an implementation advertises one or more "quic:" algorithms, it 148 MUST include them only in the SSH_MSG_KEXINIT field 149 "encryption_algorithms_client_to_server". An implementation MUST NOT 150 include "quic:" algorithms in the field 151 "encryption_algorithms_server_to_client". Implementations MUST 152 ignore "quic:" algorithms advertised by other parties in the field 153 "encryption_algorithms_server_to_client". 155 An implementation MAY advertise one or more "quic:" algorithms in the 156 first SSH key exchange. An implementation MUST NOT advertise "quic:" 157 algorithms in a subsequent SSH key re-exchange. Implementations MUST 158 ignore "quic:" algorithms advertised by other parties in subsequent 159 SSH key re-exchanges. 161 An implementation that advertises one or more "quic:" algorithms MUST 162 implement negotiation of "encryption_algorithms_client_to_server" as 163 follows: 165 1. For the SSH_MSG_KEXINIT packet from each side, define a new 166 derived name-list, "encalgs_ssh_c2s". Place into this name-list 167 all algorithm names sent by that side in the field 168 "encryption_algorithms_client_to_server", where the names DO NOT 169 begin with "quic:" (case sensitive). 171 2. For the SSH_MSG_KEXINIT packet from each side, define a new 172 derived name-list, "encalgs_quic". Place into this name-list 173 all algorithm names sent by that side in the field 174 "encryption_algorithms_client_to_server", where the names DO 175 begin with "quic:" (case sensitive). 177 3. The derived name-lists "encalgs_ssh_c2s" and "encalgs_quic" are 178 NOT sent on the wire by this protocol. 180 4. Define "neg_encalg_ssh_c2s" as the result of matching 181 "encalgs_ssh_c2s" name-lists of both sides, subject to normal 182 rules for matching encryption algorithms in [RFC4253], but 183 WITHOUT a requirement to disconnect if there is no match. 185 5. Define "neg_encalg_quic" as the result of matching 186 "encalgs_quic" name-lists of both sides, subject to normal rules 187 for matching encryption algorithms in [RFC4253], but WITHOUT a 188 requirement to disconnect if there is no match. 190 6. If "neg_encalg_ssh_c2s" is non-empty, then the SSH session MAY 191 continue over TCP, in which case this algorithm will be used as 192 the SSH client-to-server encryption algorithm. 194 7. If "neg_encalg_ssh_c2s" is empty, then the SSH session cannot 195 continue over TCP, but MAY continue over QUIC if 196 "neg_encalg_quic" is non-empty. 198 8. If "neg_encalg_quic" is non-empty, then the SSH session MAY 199 continue over QUIC, in which case this algorithm will determine 200 the TLS cipher-suite for use by QUIC. 202 9. If "neg_encalg_quic" is empty, then the SSH session cannot 203 continue over QUIC, but MAY continue over SSH if 204 "neg_encalg_ssh_c2s" is non-empty, and if other needed 205 algorithms for SSH over TCP are negotiated. 207 10. If "neg_encalg_quic" is non-empty, then if the SSH session 208 continues over QUIC, the results of matching the following name- 209 lists will become irrelevant. In this case, implementations 210 MUST NOT disconnect in advance simply if one or more of these 211 name-lists do not produce a match: 213 encryption_algorithms_server_to_client 214 mac_algorithms_client_to_server 215 mac_algorithms_server_to_client 216 compression_algorithms_client_to_server 217 compression_algorithms_server_to_client 219 Figure 2 221 2.2. Use of SSH Compression 223 If an SSH session transitions to QUIC, both sides MUST ignore the 224 results of MAC and compression negotiation in the SSH key exchange. 225 MAC functionality is replaced by the QUIC TLS cipher suite. No 226 compression is used initially. 228 After transition to QUIC, clients and servers MAY send 229 SSH_MSG_EXT_INFO as defined in [RFC8308]. The "delay-compression" 230 extension MAY be negotiated. If "delay-compression" is negotiated, 231 then compression takes effect as described in [RFC8308]. 233 This simplifies future implementations that might only implement SSH/ 234 QUIC, without SSH/TCP. Such implementations can use compression 235 negotiation that's a more exact fit for purpose than methods in 236 current SSH. 238 2.3. Use of SSH_MSG_EXT_INFO 240 This memo refers to interactions between SSH/QUIC and 241 SSH_MSG_EXT_INFO. An implementation's support for SSH/QUIC does not 242 imply support for SSH_MSG_EXT_INFO. Implementations still MUST NOT 243 send SSH_MSG_EXT_INFO to parties that did not advertise support for 244 it in SSH_MSG_KEXINIT, as described in [RFC8308]. 246 3. UDP Routability Probe 248 When a client is connecting to a server which advertises in its 249 SSH_MSG_KEXINIT a "quic:" algorithm, the client MAY probe the server 250 to discover whether UDP is supported on the network route. In this 251 case, the client MAY send to the server one or more SSH_QUIC_PROBE 252 packets with the following encoding: 254 byte pseudo-header-form : MUST equal 0x80 255 byte[4] pseudo-version : MUST equal 0x00000000 256 byte pseudo-dcid-len : MUST equal 0xFF 257 byte SSH_QUIC_PROBE : MUST equal 0x70 ('p') 258 byte probe-version : MUST equal 0x00 259 byte[32] probe-kexinit-id 260 byte n = client-cid-len (valid values: 0..20) 261 byte[n] client-cid 262 byte i = nr-client-quic-versions (valid values: 1..49) 263 uint32[i] client-quic-versions 264 byte[255] FF-padding : MUST equal 0xFFFFFF...FFFFFF 266 Figure 3 268 The client MUST send any SSH_QUIC_PROBE packets by UDP, to the same 269 server port number as the server-side TCP port for the initial SSH 270 connection. The client SHOULD send any SSH_QUIC_PROBE packets 271 promptly after receipt of the server's SSH_MSG_KEXINIT, so the 272 server's SSH_QUIC_ACK can arrive before completion of SSH key 273 exchange. Servers MUST NOT expect the client's IP address or UDP 274 port number to match the address or client-side port in the TCP 275 connection. 277 If a client sends multiple SSH_QUIC_PROBE packets for the same SSH 278 connection, the packets MUST be identical. A server that receives 279 different SSH_QUIC_PROBE packets MAY treat any one as authoritative 280 and discard the rest. 282 The layout of SSH_QUIC_PROBE is crafted so the packet resembles a 283 clearly invalid QUIC Version Negotiation Packet [QUIC]. The packet 284 has byte values 255 at offsets corresponding to Version Negotiation 285 Packet fields "Destination Connection ID Length" and "Source 286 Connection ID Length", and the packet is shorter than these values 287 require. This allows SSH_QUIC_PROBE to be detected and handled 288 separately from QUIC packets received on the same UDP port. 290 Servers MUST verify that received SSH_QUIC_PROBE packets have the 291 expected length and that the fixed-value fields have their expected 292 values. Packets with different lengths or values MUST be ignored, or 293 passed to the QUIC implementation if they could be valid QUIC 294 packets. 296 A server MUST ignore any SSH_QUIC_PROBE with an unrecognized value of 297 "probe-version". Currently, 0 is the only valid value in this field. 299 The field "probe-kexinit-id" contains a SHA-256 hash of the following 300 data: 302 byte 0x70 ('p') 303 byte[16] cookie field from server's SSH_MSG_KEXINIT 305 Figure 4 307 A server MUST verify that the field "probe-kexinit-id" matches a 308 recent server-side SSH_MSG_KEXINIT, sent by this server, during 309 initial key exchange, on an incoming SSH connection, where the 310 initial key exchange has not yet completed. If a server cannot 311 verify this, it MUST ignore the SSH_QUIC_PROBE. 313 The field "client-cid-len" contains the length of the client's QUIC 314 connection ID. This MUST be a value between 0 and 20, inclusive, 315 which is the current QUIC limit for the length of connection IDs. 317 The field "client-cid" contains the client's QUIC connection ID, if 318 any. This will be used by the server as the Destination Connection 319 ID in its first QUIC packets sent to the client. 321 The field "quic-scid-len" always appears at the same offset from the 322 start of the packet. Together with other fixed-value fields, it 323 helps detect that the packet is a valid SSH_QUIC_PROBE. 325 The field "nr-client-quic-versions" contains the number of QUIC 326 protocol versions for which the client advertises support. The 327 number of versions MUST NOT exceed 48 so the packet is not 328 interpreted as a valid QUIC Version Negotiation Packet. 330 The field "client-quic-versions" enumerates the QUIC protocol 331 versions for which the client advertises support. 333 The field "FF-padding" contains exactly 255 bytes which MUST all have 334 value 0xFF. This field ensures that SSH_QUIC_PROBE is not a valid 335 QUIC Version Negotiation Packet, and that it is larger than 336 SSH_QUIC_ACK. This helps prevent these packets being used in 337 Amplified Reflection DDoS. Servers MUST ignore SSH_QUIC_PROBE 338 packets where the padding is of an incorrect length or contains 339 incorrect values. 341 There MUST NOT be any further packet data after the defined fields. 342 Servers MUST ignore SSH_QUIC_PROBE packets that contain unexpected 343 data. 345 3.1. UDP Probe Acknowledgment 347 For each SSH_QUIC_PROBE packet that passes the server's validation, 348 the server MUST respond with exactly one SSH_QUIC_ACK: 350 byte quic-header-form : MUST equal 0x80 351 byte[4] quic-version : MUST equal 0x00000000 352 byte quic-dcid-len : MUST equal 0xFF 353 byte SSH_QUIC_ACK : MUST equal 0x61 ('a') 354 byte ack-version : MUST equal 0x00 355 byte[32] ack-kexinit-id 356 byte n = server-cid-len (valid values: 0..20) 357 byte[n] server-cid 358 byte i = nr-server-quic-versions (valid values: 1..49) 359 uint32[i] server-quic-versions 361 Figure 5 363 This follows a similar construction as SSH_QUIC_PROBE, resembling a 364 clearly invalid QUIC Version Negotiation Packet [QUIC]. It is 365 shorter than SSH_QUIC_PROBE to help prevent its use in Amplified 366 Reflection DDoS. 368 If a server sends multiple SSH_QUIC_ACK packets for the same SSH 369 connection, the packets MUST be identical. A client that receives 370 different SSH_QUIC_ACK packets MAY treat any one as authoritative and 371 discard the rest. 373 Clients MUST verify that received SSH_QUIC_ACK packets have the 374 expected length and that the fixed-value fields have their expected 375 values. Packets with different lengths or values MUST be ignored, or 376 passed to the QUIC implementation if they could be valid QUIC 377 packets. 379 A client MUST ignore any SSH_QUIC_ACK with an unrecognized value of 380 "ack-version". Currently, 0 is the only valid value in this field. 382 The field "ack-kexinit-id" contains a SHA-256 hash of the following 383 data: 385 byte 0x61 ('a') 386 byte[16] cookie field from server's SSH_MSG_KEXINIT 388 Figure 6 390 This field is ALSO calculated on the basis of the server's 391 SSH_MSG_KEXINIT. This allows a server to respond to SSH_QUIC_PROBE 392 even if it arrives before the client's SSH_MSG_KEXINIT. 394 A client MUST verify that the fields "probe-id" and "ack-kexinit-id" 395 match a recent SSH_QUIC_PROBE for which this client is expecting an 396 SSH_QUIC_ACK. If a client cannot verify this, it MUST ignore the 397 SSH_QUIC_ACK. 399 The field "server-cid-len" contains the length of the server's QUIC 400 connection ID. This MUST be a value between 0 and 20, inclusive, 401 which is the current QUIC limit for the length of connection IDs. 403 The field "server-cid" contains the server's QUIC connection ID, if 404 any. This will be used by the client as the Destination Connection 405 ID in its first QUIC packets sent to the server. 407 The field "nr-server-quic-versions" contains the number of QUIC 408 protocol versions for which the server advertises support. The 409 number of versions MUST NOT exceed 48 so the packet is not 410 interpreted as a valid QUIC Version Negotiation Packet. 412 The field "server-quic-versions" enumerates the QUIC protocol 413 versions for which the server advertises support. 415 There MUST NOT be any further packet data after the defined fields. 416 Clients MUST ignore SSH_QUIC_ACK packets that contain unexpected 417 data. 419 4. Transition Using SSH_MSG_NEWKEYS 421 At the end of the first SSH key exchange, a client MAY transition the 422 session to QUIC if all of the following conditions are met: 424 * The initial SSH key exchange produces a non-empty 425 "neg_encalg_quic" value. 427 * The client received at least one valid SSH_QUIC_ACK in response to 428 its SSH_QUIC_PROBE. 430 * The client and the server advertised at least one mutually 431 supported QUIC version in their SSH_QUIC_PROBE and SSH_QUIC_ACK. 433 In these conditions, the client MAY transition to QUIC by sending an 434 extended SSH_MSG_NEWKEYS packet, referred to as QUIC-NEWKEYS. The 435 client sends this packet at the usual point, when it completes its 436 first outgoing SSH key exchange: 438 byte SSH_MSG_NEWKEYS 439 string "quic" 441 Figure 7 443 A client MUST NOT send a QUIC-NEWKEYS in a non-first key exchange. A 444 server MUST NOT send it - it MUST send the usual SSH_MSG_NEWKEYS. 445 Clients and servers that receive QUIC-NEWKEYS unexpectedly MAY 446 disconnect. 448 After sending QUIC-NEWKEYS, a client MUST NOT send any further 449 packets on the TCP connection. A server MUST disconnect if it 450 receives any further packets from the client over TCP. 452 If a server receives an appropriate QUIC-NEWKEYS, then if the server 453 has not yet done so, it MUST send its first SSH_MSG_NEWKEYS. This 454 MUST be the last packet sent by the server on the TCP connection. 456 The server MAY send its SSH_MSG_NEWKEYS before it has received the 457 client's SSH_MSG_NEWKEYS or QUIC-NEWKEYS. In this case, the server 458 might also want to send SSH_MSG_EXT_INFO, but does not yet know if 459 the client will continue the connection over QUIC or TCP. In this 460 case, the server MUST wait to send SSH_MSG_EXT_INFO until it receives 461 either SSH_MSG_NEWKEYS or QUIC-NEWKEYS. 463 If a client sent QUIC-NEWKEYS, it MUST disconnect if the server sends 464 any further packets over TCP after the server's SSH_MSG_NEWKEYS. 466 All subsequent SSH packets sent by the server and client are sent 467 over QUIC. After the client sent QUIC-NEWKEYS, and the server sent 468 SSH_MSG_NEWKEYS, either side MAY disconnect the TCP connection. 469 However, a client that wants to continue the session MUST wait to 470 disconnect until it has received the server's SSH_MSG_NEWKEYS. If a 471 server receives a TCP disconnect before it successfully sent 472 SSH_MSG_NEWKEYS, it MAY terminate the SSH connection. 474 In most cases, the first SSH packet the client sends over QUIC will 475 be SSH_MSG_SERVICE_REQUEST. The server MAY send SSH_MSG_EXT_INFO as 476 its first QUIC packet, after receiving the client's QUIC-NEWKEYS. 477 Otherwise, the server's first QUIC packet will likely be 478 SSH_MSG_SERVICE_ACCEPT. Either side MAY also send other packets 479 normally permitted in this SSH connection stage, including 480 SSH_MSG_IGNORE, SSH_MSG_UNIMPLEMENTED, SSH_MSG_DEBUG, or 481 SSH_MSG_DISCONNECT. 483 After an SSH session transitions to QUIC, implementations MUST NOT 484 send any further SSH packets with message numbers 20-49. This 485 includes SSH_MSG_KEXINIT, SSH_MSG_NEWKEYS and key exchange packets. 486 If a client or server receives SSH packets with such message numbers 487 over QUIC, it MUST respond with SSH_MSG_UNIMPLEMENTED. 489 Due to network routing issues beyond the client's and server's 490 control, clients and servers MUST be prepared to receive the first 491 QUIC packets before the other party's QUIC-NEWKEYS or SSH_MSG_NEWKEYS 492 arrives over TCP. A receiver SHOULD detect such UDP datagrams by 493 their QUIC Destination Connection ID, buffer them, and defer their 494 QUIC processing until the expected QUIC-NEWKEYS or SSH_MSG_NEWKEYS is 495 received. A receiver SHOULD be prepared to buffer at least 100,000 496 bytes of such packets, measured as the sum of UDP datagram lengths. 497 To the extent the receiver cannot buffer such packets, it MUST drop 498 them, potentially causing the sender to resend. If a server has 499 buffered such packets, but the client then sends a regular 500 SSH_MSG_NEWKEYS instead of QUIC-NEWKEYS, the server MUST drop the 501 buffered packets along with related QUIC session state and continue 502 the SSH session over TCP. 504 5. QUIC Setup 506 On transition to QUIC [QUIC] [QUIC-TLS], the QUIC session is set up 507 as follows: 509 * The QUIC protocol version is set to the first version advertised 510 in the client's SSH_QUIC_PROBE which is also present in the 511 server's SSH_QUIC_ACK. 513 * Session state is set as if a TLS handshake had just completed. 515 * The TLS cipher suite is set as identified by "neg_encalg_quic". 517 * The QUIC Key Phase bit is set to 0. 519 * Shared secrets that would have been obtained from the TLS 520 handshake are generated from the SSH key exchange and the 521 SSH_QUIC_PROBE and SSH_QUIC_ACK packets. 523 Clients and servers always can, and therefore MUST, immediately begin 524 to use QUIC Short Header Packets. Implementations MUST NOT send QUIC 525 Long Header Packets and MUST ignore them. 527 5.1. Shared Secrets 529 QUIC-TLS [QUIC-TLS] uses a client secret and a server secret from 530 which it generates an AEAD key, an IV, and a header protection key 531 for each sending direction. 533 An SSH key exchange produces a shared secret K, represented as an SSH 534 multi-precision integer, and an exchange digest H, represented as 535 binary data [RFC4253]. An SSH key exchange is parameterized with a 536 hash function we call HASH. Note that HASH can be a different hash 537 function, producing a different hash length, than the hash function 538 used by the TLS cipher suite negotiated in "neg_encalg_quic". 540 To compute the initial QUIC client and server secrets, the client and 541 server encode the following binary data, which we call "secret_data": 543 secret_data: 544 mpint K 545 string H 546 string UDP datagram content of SSH_QUIC_PROBE 547 string UDP datagram content of SSH_QUIC_ACK 549 Figure 8 551 The client and server secrets are then calculated as follows: 553 client_secret = HMAC-HASH("ssh/quic client", secret_data) 554 server_secret = HMAC-HASH("ssh/quic server", secret_data) 556 Figure 9 558 The HMAC construct is as specified in [RFC2104], instantiated using 559 the SSH key exchange hash function, HASH. 561 QUIC keys and IVs are derived from these secrets using the regular 562 QUIC-TLS key derivation process [QUIC-TLS]. Keys generated from 563 these secrets are considered 1-RTT keys. 565 Clients and servers MUST implement QUIC key updates using the regular 566 QUIC-TLS key update process [QUIC-TLS], respecting the QUIC-TLS 567 minimum key update frequencies. 569 6. SSH/QUIC Packet Format 571 All SSH/QUIC packets are sent on QUIC stream 0. No other QUIC 572 streams are used in SSH over QUIC. 574 Each side serializes its SSH packets for sending over QUIC as 575 follows: 577 uint32 n = payload-len 578 byte[n] payload 580 Figure 10 582 Since security is provided by QUIC-TLS [QUIC-TLS], MAC and random 583 padding are omitted at this stage. 585 In SSH/QUIC, compression algorithms negotiated in the initial SSH key 586 exchange are ignored. Such compression does NOT take effect. 588 Compression MAY be negotiated using the "delay-compression" extension 589 in [RFC8308]. If "delay-compression" is negotiated, and conditions 590 to enable compression are met, then the "payload" field is 591 compressed. 593 Otherwise, the "payload" field contains the same packet information 594 as the "payload" field in the Binary Packet Protocol defined in 595 [RFC4253]. 597 7. IANA Considerations 599 IANA is requested to update the "Secure Shell (SSH) Protocol 600 Parameters" registry, established with [RFC4250], to add the 601 following entries to the table "Encryption Algorithm Names" 602 [IANA-EAN]: 604 Encryption Algorithm Name Reference Note 605 quic:aes128-gcm-sha256 [this document] 606 quic:aes256-gcm-sha384 [this document] 607 quic:chacha20-poly1305-sha256 [this document] 608 quic:aes128-ccm-sha256 [this document] 610 Figure 11 612 8. Security Considerations 614 The security considerations of [RFC4251] apply to this document. 616 9. References 618 9.1. Normative References 620 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 621 and Secure Transport", 2020, . 624 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 625 2020, 626 . 628 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 629 Hashing for Message Authentication", RFC 2104, 630 DOI 10.17487/RFC2104, February 1997, 631 . 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, 635 DOI 10.17487/RFC2119, March 1997, 636 . 638 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 639 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 640 January 2006, . 642 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 643 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 644 January 2006, . 646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 648 May 2017, . 650 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 651 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 652 2018, . 654 9.2. Informative References 656 [IANA-EAN] IANA, "Secure Shell (SSH) Encryption Algorithm Names", 657 . 659 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 660 Protocol Assigned Numbers", RFC 4250, 661 DOI 10.17487/RFC4250, January 2006, 662 . 664 Author's Address 665 denis bider 666 Bitvise Limited 667 4105 Lombardy Ct 668 Colleyville, TX 76034 669 United States 671 Email: ietf-draft@denisbider.com