Hi Hannes, When you say a "*security* feature like ECH", I guess it depends on one's definition of security.
ECH is not a security feature per se. The most that the draft states regarding security is that it aims to not weaken the existing security of TLS. I.e. security preservation. See Section 10.1 of the ECH draft as reference. What ECH does aim to achieve though, is handshake privacy. Ironically, again depending on your viewpoint on security, it may actually decrease overall security in the process, by possibly making it more difficult, or at the very least less efficient due to extra round trips, to scan connections for malicious payload by TLS intercepting appliances and/or SNI based protection engines. But yes, what I am talking about is disabling ECH by an entity/appliance other than the endpoints. One that is authoritative for the public name, of course. As you will see in other emails in this thread, this is not new and is already addressed in the draft. Thanks, SB On Wed, Oct 19, 2022 at 2:49 AM Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > Giving someone, other than those managing the endpoints, the ability to > disable a security feature like ECH is problematic. > > > > If I read your email correctly then I believe that’s what you are > suggesting. I hope I am missing something. > > > > Ciao > > Hannes > > > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of * Safe Browsing > *Sent:* Wednesday, October 19, 2022 4:56 AM > *To:* Eric Rescorla <e...@rtfm.com> > *Cc:* TLS@ietf.org > *Subject:* Re: [TLS] Securely disabling ECH > > > > Hi Eric, > > > > Picking up on your (earlier) reply here. > > > > Though it would be possible to adjust the setting in browsers (disabling > ECH), this is not an ideal/sufficient method of disabling ECH. > > > > Some reasons it is not sufficient: > > - Not all TLS clients are browsers > > - Not all browsers (or other TLS clients) may implement this ability > > - In a multi-browser environment it means that it needs to be configured > in more than one place, each using a different method of achieving the same > (cumbersome) > > - even worse if there are other, non-browser, ECH supporting clients > present for which ECH needs to be disabled > > > > It seems therefore that the ideal place to achieve this is within the > protocol itself. Making ECH disabling client agnostic. > > > > 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” > > > > 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 > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
