It sounds like your confusion is stemming from section 6.1.6. Upon re-reading it, I see some room for clarity there.
Section 6.1.6 says what to do if "retry_configs" contains a value with a client-supported version (retry with with one of those configs), and what to do if "none of the values provided in "retry_configs" contains a supported version, or an earlier TLS version was negotiated" (retry without ECH). My implied reading of section 6.1.6 is that if there is no "retry_configs", then the latter also applies (retry without ECH). That could be made more explicit. I disagree that any particular retry behavior should be mandated. Clients that want wide interoperability will implement retry without ECH whether or not the spec says it's a MUST, and likewise clients that will only connect if ECH is used will choose to not implement the fallback regardless of what the spec says. On Wed, Oct 19, 2022 at 8:36 PM Safe Browsing <safebrowsing...@gmail.com> wrote: > Hi Nick, > > Thanks for your input. > > Yes, what I am suggesting is instead of having: "Depending on whether X, > this may Y or Z". > Rather state: "If X, then MUST Y, else MUST Z" > > So, instead of this text in Section 8.2: > > "Depending on whether the client is configured to accept the proxy's > certificate as authoritative for the public name, this may trigger the > retry logic described in Section 6.1.6 > <https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html#rejected-ech> > or result in a connection failure. ..." > > Have something like this: > > "*If* the client is configured to accept the proxy's certificate as > authoritative for the public name, the retry logic described in Section > 6.1.6 > <https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html#rejected-ech> > *MUST* be exercised. Else, a connection failure *MUST* result. ..." > > Note that the second 'MUST' (the one in the 'else' case) is not new. It is > already stated in the first paragraph in Section 6.1.6 as required behavior. > > Also note that the retry in this case would not involve the > "retry_configs" method mentioned in Section 6.1.6. Instead, it would be > retrying the handshake with a new transport connection and ECH disabled. > This, ECH disabled retry, is mentioned in Section 6.1.6, but only in the > context of "retry_configs" containing non-supported versions, or if an > earlier TLS version was negotiated. > > Thus, as I also stated in one of my earlier emails, Section 6.1.6 is not > very clear about the retry mechanism to be followed in the case discussed > here. > > A suggestion for changing the text of one of the paragraphs of Section > 6.1.6, to be more clear/explicit, would be to change: > > "If none of the values provided in "retry_configs" contains a supported > version, or an earlier TLS version was negotiated, the client can regard > ECH as securely disabled by the server, and it SHOULD retry the handshake > with a new transport connection and ECH disabled." > > To: > > "If none of the values provided in "retry_configs" contains a supported > version, or an earlier TLS version was negotiated, *or an > **"encrypted_client_hello" > extension was not supplied by the server,* the client can regard ECH as > securely disabled by the server, and it *MUST* retry the handshake with a > new transport connection and ECH disabled." > > This type of retry would be required only once, and a precondition for > this "securely disabled" state is already stated in one of the earlier > paragraphs in the same section. Namely, that the server/certificate must be > authoritative for the public name. > > Again the 'MUST' in this suggested text. Note that it does not pertain to > the "retry_configs", as stated already. But rather to the case where ECH > has been disabled securely, in which case it would be good if the > specification can provide the way a stack must operate in such a situation > which the specification prescribes. I believe having a MUST here, and in > the previous instance mentioned at the top of this email, will make stacks > that wish to comply with the specification much more likely to to implement > this retry mechanism, resulting in a more robust ECH deployment and > operating environment. > > To the comment about Section 8.1. Yes, that section has this text that is > relevant here: > > "If the server does not understand the "encrypted_client_hello" extension > at all, it will ignore it as required by Section 4.1.2 > <https://rfc-editor.org/rfc/rfc8446#section-4.1.2> of [RFC8446 > <https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html#RFC8446>]. > Provided the server can present a certificate valid for the public name, > the client can safely retry with updated settings, as described in Section > 6.1.6 > <https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html#rejected-ech> > ." > > So it simply refers back to Section 6.1.6 again, which then gets back to > my earlier statement about Section 6.1.6 not being as clear as it can be > about this situation. I.e. the situation were a retry is with ECH disabled, > due to the lack of an ECH extension from the server, as opposed to the > "retry_config" retry method with ECH still enabled - they are of course > very different retry mechanisms. > > > On Wed, Oct 19, 2022 at 1:44 AM Nick Harper <i...@nharper.org> wrote: > >> >> >> On Tue, Oct 18, 2022 at 8:56 PM Safe Browsing <safebrowsing...@gmail.com> >> wrote: >> >>> The draft does consider this by allowing ECH to be disabled - as >>> discussed in this thread. Albeit at the cost of an extra round trip. >>> However, the connection retry logic in the presence of ECH disabling is >>> currently optional. >>> >>> The draft states, in Section 8.2: >>> “ this may trigger the retry logic” >>> >>> It seems this text must change to: >>> “ this MUST trigger the retry logic” >>> >> >> This language change would not make sense. The context for "this may >> trigger the retry logic" in section 8.2 offers two options. The sentence >> structure is "Depending on whether X, this may Y or Z", i.e. if X is >> resolved one way, then the client does Y, otherwise it does Z. Changing the >> "may" to "MUST" would result in stating "this MUST trigger the retry logic >> described in Section 6.1.6 or result in a connection failure", which >> doesn't really make sense, and wouldn't have the goal you'd like, since a >> connection failure instead of retry logic would satisfy the MUST. >> >> If your server is authoritative for the public name, then the behavior >> you care about is described in section 8.1. >> >> I suspect most implementations of ECH will implement the retry logic, as >> the misconfigurations and deployment concerns described in section 8.1 are >> an inevitability, and implementing the retry logic avoids connection >> failures that would occur without it. I doubt that adding a MUST would make >> someone more likely to implement the retry logic. >> >>> >>> In order to ensure functional connections in a TLS client agnostic >>> manner, in the presence of protocol level ECH disabling. >>> >>> I would appreciate your thoughts/input. >>> >>> On Oct 8, 2022, at 7:41 PM, Eric Rescorla <e...@rtfm.com> wrote: >>> >>> >>> If you are able to install a new trust anchor, then you should be able >>> to use the enterprise configuration mechanisms in browsers to disable ECH. >>> >>> -Ekr >>> >>> >>> On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing <safebrowsing...@gmail.com> >>> wrote: >>> >>>> Hi Rich, >>>> >>>> When I say “authoritative”, I mean it in the true TLS sense, in the way >>>> that I believe the ECH draft also suggests and requires. >>>> >>>> In other words, the middlebox serves a cert to the client that is >>>> cryptographically valid for the said public name of the client facing >>>> server. >>>> >>>> How can that be when the client facing server guards its private key >>>> properly? By re-signing the server certificate on the middlebox with a >>>> private key, local to the middle box only, for which the corresponding >>>> certificate has been installed in the trust store of the client, before >>>> sending it on to the client. Only after the original server >>>> certificate has been validated properly on the middlebox, of course. >>>> Message >>>> digests being managed accordingly/appropriately. >>>> >>>> That is a very typical setup for most (all?) TLS inspection devices >>>> (next gen firewalls and such). >>>> >>>> Thus this part of ECH, requiring the middlebox to be authoritative for >>>> the server, is well understood and prolifically exercised in inspected TLS >>>> sessions today. What is new is that these connections can now fail/close, >>>> in the “securely disabling ECH” case, and the onus is on the TLS client, >>>> not the application, to retry the connection without ECH. >>>> >>>> I am after such a client, if one exists already. >>>> >>>> Thank you. >>>> >>>> Sent from my phone >>>> >>>> On Oct 7, 2022, at 11:41 AM, Salz, Rich <rs...@akamai.com> wrote: >>>> >>>> >>>> >>>> >>>> >>>> - Client <-> *Middlebox* <-> Client-facing server <-> Backend server >>>> >>>> >>>> >>>> - With "Middlebox" really meaning a middlebox like a firewall or >>>> similar. >>>> >>>> >>>> >>>> The middlebox is not allowed to modify traffic between the client and >>>> the server. Doing so would mean that the packets the client sent are not >>>> the ones that the server received, and the two message digests would >>>> disagree. (If you think about things, it **has** to be this way, >>>> otherwise TLS would not be able to provide integrity guarantees.) >>>> >>>> >>>> >>>> - From the draft, ECH seems to be designed to still allow >>>> successful TLS connection establishment if the encrypted_client_hello >>>> extension is dropped from the ClientHello on a conforming middlebox. >>>> Provided that the middlebox is authoritative for the client-facing >>>> server's >>>> public name, as reported/delivered by DNS to the client. We can assume >>>> that >>>> this is the case here. >>>> >>>> >>>> >>>> I do not understand what you mean by this. The word “authoritative” is >>>> used to mean that it has a certificate and keypair and can do TLS >>>> termination. DNS giving the client a particular IP address is not >>>> authoritative. It can be confusing because DNS terminology uses >>>> authoritative to mean that a particular entity can prepare data used for >>>> DNS responses. But it is not authoritative in the TLS sense. >>>> >>>> >>>> >>>> I think your questions can be answered with those two overall >>>> corrections above. If not, please continue the thread. (And feel free to >>>> repost from your note since I trimmed for brevity.) >>>> >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
