From 6aa493114e0c57b369242ca31d4ddd26fbbd62d4 Mon Sep 17 00:00:00 2001 From: Kenichi Ishibashi Date: Sun, 15 Oct 2023 15:01:19 +0900 Subject: [PATCH 1/2] Add a section for connection establishment To discuss how to handle SVCB-reliant clients such as ECH. --- draft-happy-eyeballs-v3.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/draft-happy-eyeballs-v3.md b/draft-happy-eyeballs-v3.md index 89a0b83..c31e7bf 100644 --- a/draft-happy-eyeballs-v3.md +++ b/draft-happy-eyeballs-v3.md @@ -306,6 +306,32 @@ Delay SHOULD have an upper bound, referred to as the "Maximum Connection Attempt Delay". The current recommended value is 2 seconds. +## Establishing connections + +Each application can have different semantics for establishing a connection. +Typically, connection establishment consists of one or more handshakes. This +document addresses two types of handshakes: + +- Transport layer handshake, where peers establish a reliable, in-order data + stream. +- Cryptographic handshake, where peers establish a secure channel for + communication. + +For example, plain HTTP only requires a transport layer handshake (i.e., TCP +handshake). HTTP with TLS necessitates a cryptographic handshake (i.e., TLS +handshake) in addition to the TCP handshake. QUIC version 1 combines both +cryptographic and transport handshakes into a single handshake. + +While transport layer handshakes generally do not have restrictions on attempts +to establish a connection, some cryptographic handshakes may be dependent on +ServiceMode SVCB RRs and could impose limitations on establishing a connection. +For instance, ECH-capable clients may become SVCB-reliant clients +({{!SVCB=I-D.ietf-dnsop-svcb-https, Section 3}}) when SVCB RRs contain the +"ech" SvcParamKey. If the client is either an SVCB-reliant client or a +SVCB-optional client that might switch to SVCB-reliant connection +establishment during the process, the client MUST wait for SVCB RRs before +proceeding with the cryptographic handshake. + # DNS Answer Changes During Happy Eyeballs Connection Setup {#changes} If, during the course of connection establishment, the DNS answers From 97812b2325931261334615faedf21bffbc775ff9 Mon Sep 17 00:00:00 2001 From: bashi Date: Thu, 19 Oct 2023 08:21:24 +0900 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Tommy Pauly --- draft-happy-eyeballs-v3.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/draft-happy-eyeballs-v3.md b/draft-happy-eyeballs-v3.md index c31e7bf..94863c4 100644 --- a/draft-happy-eyeballs-v3.md +++ b/draft-happy-eyeballs-v3.md @@ -306,28 +306,28 @@ Delay SHOULD have an upper bound, referred to as the "Maximum Connection Attempt Delay". The current recommended value is 2 seconds. -## Establishing connections - -Each application can have different semantics for establishing a connection. -Typically, connection establishment consists of one or more handshakes. This -document addresses two types of handshakes: - -- Transport layer handshake, where peers establish a reliable, in-order data - stream. -- Cryptographic handshake, where peers establish a secure channel for - communication. - -For example, plain HTTP only requires a transport layer handshake (i.e., TCP -handshake). HTTP with TLS necessitates a cryptographic handshake (i.e., TLS -handshake) in addition to the TCP handshake. QUIC version 1 combines both -cryptographic and transport handshakes into a single handshake. +## Determining successful connection establishment + +The determination of when a connection attempt has successfully completed +(and other attempts can be cancelled) depends on the protocols being used +to establish a connection. This can involve one or more protocol handshakes. + +Client connections that use TCP only (without TLS or another protocol on top, such +as for unencrypted HTTP connections) will determine successful establishment based +on completing the TCP handshake only. When TLS is used on top of of TCP (such +as for encrypted HTTP connections), clients MAY choose to wait for the TLS handshake to +successfully complete before cancelling other connection attempts. This is particularly +useful for networks in which a TCP-terminating proxy might be causing TCP handshakes +to succeed quickly, even though end-to-end connectivity with the TLS-terminating +server will fail. QUIC connections inherently include a secure handshake in their main +handshakes, and thus only need to wait for a single handshake to complete. While transport layer handshakes generally do not have restrictions on attempts to establish a connection, some cryptographic handshakes may be dependent on ServiceMode SVCB RRs and could impose limitations on establishing a connection. For instance, ECH-capable clients may become SVCB-reliant clients -({{!SVCB=I-D.ietf-dnsop-svcb-https, Section 3}}) when SVCB RRs contain the -"ech" SvcParamKey. If the client is either an SVCB-reliant client or a +({{Section 3 of SVCB}}) when SVCB RRs contain the +"ech" SvcParamKey {{!ECH=I-D.ietf-tls-svcb-ech}}. If the client is either an SVCB-reliant client or a SVCB-optional client that might switch to SVCB-reliant connection establishment during the process, the client MUST wait for SVCB RRs before proceeding with the cryptographic handshake.