[TLS] Securely disabling ECH
Good day, The ECH draft describes a method for securely disabling ECH - at the cost of an extra round trip. Is there a client and server implementation that supports this functionality already - securely disabling ECH? SB ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Securely disabling ECH
Yes, that is it. Via section 8.2: 8.2. Middleboxes When connecting through a TLS-terminating proxy that does not support this extension, [RFC8446], Section 9.3 requires the proxy still act as a conforming TLS client and server. The proxy must ignore unknown parameters, and generate its own ClientHello containing only parameters it understands. Thus, when presenting a certificate to the client or sending a ClientHello to the server, the proxy will act as if connecting to the public name, without echoing the "encrypted_client_hello" extension. 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 or result in a connection failure. A proxy which is not authoritative for the public name cannot forge a signal to disable ECH. Is there a TLS client with ECH support available, implementing ECH disabling in such a manner that invokes the retry logic to achieve a successful connection when the middlebox removes/filters the ECH extension? > On Sep 19, 2022, at 5:10 PM, Eric Rescorla wrote: > > > Are you referring to this text in 6.1.6 or something else? > > "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." > > -Ekr > > > >> On Mon, Sep 19, 2022 at 11:20 AM Safe Browsing >> wrote: >> Good day, >> >> The ECH draft describes a method for securely disabling ECH - at the cost of >> an extra round trip. Is there a client and server implementation that >> supports this functionality already - securely disabling ECH? >> >> SB >> ___ >> 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
Re: [TLS] Securely disabling ECH
Hi there, There have been no replies on this. I am wondering if it means that TLS client implementations will not support this (retry logic on securely disabled ECH), or just that it has not been implemented yet. The wording “may trigger the retry logic” from the draft is maybe a hint of the intension. I would like to request the ECH implementers of the various stacks to comment on this please. I suppose the same question should be asked on the QUIC WG also. Though not exactly the same since the “middlebox“ section is not in the QUIC ECH draft. Thanks, SB > On Sep 20, 2022, at 9:35 AM, Safe Browsing wrote: > > Yes, that is it. Via section 8.2: > > 8.2. Middleboxes > > When connecting through a TLS-terminating proxy that does not support this > extension, [RFC8446], Section 9.3 requires the proxy still act as a > conforming TLS client and server. The proxy must ignore unknown parameters, > and generate its own ClientHello containing only parameters it understands. > Thus, when presenting a certificate to the client or sending a ClientHello to > the server, the proxy will act as if connecting to the public name, without > echoing the "encrypted_client_hello" extension. > > 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 or result in a connection failure. A proxy > which is not authoritative for the public name cannot forge a signal to > disable ECH. > > > Is there a TLS client with ECH support available, implementing ECH disabling > in such a manner that invokes the retry logic to achieve a successful > connection when the middlebox removes/filters the ECH extension? > > >>> On Sep 19, 2022, at 5:10 PM, Eric Rescorla wrote: >>> >> >> Are you referring to this text in 6.1.6 or something else? >> >> "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." >> >> -Ekr >> >> >> >>> On Mon, Sep 19, 2022 at 11:20 AM Safe Browsing >>> wrote: >>> Good day, >>> >>> The ECH draft describes a method for securely disabling ECH - at the cost >>> of an extra round trip. Is there a client and server implementation that >>> supports this functionality already - securely disabling ECH? >>> >>> SB >>> ___ >>> 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
Re: [TLS] Securely disabling ECH
Hi Rich and Eric, Thanks for the replies. Let me add to the picture: Client <-> *Middlebox* <-> TLS terminating <-> Desired Origin Or to put it in the TLS ECH draft terminology (split mode topology) - as per my understanding - : Client <-> *Middlebox* <-> Client-facing server <-> Backend server With "Middlebox" really meaning a middlebox like a firewall or similar. >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. >From Section 7: " If the "encrypted_client_hello" is not present [in the ClientHello], then the server completes the handshake normally, as described in [RFC8446]." >From Section 6.1.4: " If the message is a ServerHello, the client computes accept_confirmation as described in Section 7.2. If this value matches the last 8 bytes of ServerHello.random, the server has accepted ECH. Otherwise, it has rejected ECH." In this case, ECH will of course be deemed "rejected". >From Section 6.1.6: "If both authentication and the handshake complete successfully, the client MUST perform the processing described below then abort the connection with an "ech_required" alert before sending any application data to the server." Both authentication and the handshake should complete successfully here. Section 6.1.6 also states: " 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." This part does not make it very clear whether ECH should be regarded as being "securely disabled" when the ServerHello does not contain the encrypted_client_hello extension at all, since the paragraph in which "securely disabled" is mentioned presupposes the presence of "retry_configs". I am assuming that is the intention though - that a non-ECHed ServerHello + authenticated cert will lead to ECH being securely disabled, in turn triggering the retry mechanism. >From Section 6.1.7: "The TLS implementation MUST NOT report such connections as successful to the application." and "These connections are only used to trigger retries, as described in Section 6.1.6." It is this retry mechanism that I am after. This is something that is to be implemented on the ECH supporting client. I would like to test this functionality with such a middlebox in-line, but need a client that already supports the connection retry attempt when ECH got disabled in this way. Is my understanding above correct, and if so, does anyone know if such a client implementation is available already? I hope this is clearer. Thanks, SB On Tue, Oct 4, 2022 at 11:19 AM Salz, Rich wrote: > I do not understand your question. Let me start with a picture. > > > > Client <-> TLS terminating <-> Desired Origin > > Concretely for an example: > > Browser <-> a CDN <-> origin for www.example.com > > > > The key phrase is the middle entity is a TLS terminating one. (As opposed > to a conventional firewall or similar that just forwards packets, which is > why I say “middle entity” rather than “middle box” > > > > In order to connect to the CDN, it must have a certificate for > www.example.com and DNS must have sent the browser to the CDN. If not, > the browser will fail the connection. > > > > In order to avoid confusion with their own IT structure, it is common for > the “Example, Com” entity to actually have a different name for their > origin website, call it origin.example.com > > > > So, can you rephrase your question perhaps? > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Securely disabling ECH
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 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
Re: [TLS] Securely disabling ECH
Thank you Dennis. Will give it a try. Best regards, SB On Mon, Oct 10, 2022 at 11:07 AM Dennis Jackson wrote: > You and "SB" are in agreement. There is a middlebox terminating the TLS > connection with a cert chain signed by a root which is also installed on > the client. The middlebox in turn is connecting to a TLS Server whose cert > chains back to a webpki root. The middlebox is handling the termination and > re-encryption of the client's traffic. > > In any case, SB's question was about whether this would trigger the ECH > retry behavior (yes, since it appears to the client as though the middlebox > is the server) and whether at least one client already implemented it (yes, > Firefox). > > Best, > Dennis > On 10/10/2022 14:04, Salz, Rich wrote: > > >- 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. > > > > The only way that happens is if the middlebox **terminates the TLS > connection** In this case it is like my client<>cdn<>origin picture. > The middlebox cannot present a certificate and then hand-off a connection > to the server. > > > > I must not be getting something important to you. > > > > ___ > TLS mailing listTLS@ietf.orghttps://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
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 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 > 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 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
Re: [TLS] Securely disabling ECH
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 wrote: > > > On Tue, Oct 18, 2022 at 8:56 PM Safe Browsing > 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 sens
Re: [TLS] Securely disabling ECH
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 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 *On Behalf Of * Safe Browsing > *Sent:* Wednesday, October 19, 2022 4:56 AM > *To:* Eric Rescorla > *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 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 > 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. > &g
Re: [TLS] Securely disabling ECH
Hi Christian, For transparent proxies, no. Thanks On Wed, Oct 19, 2022 at 4:51 AM Christian Huitema wrote: > If one connects to a proxy, shouldn't the SNI point to the name of the > proxy? > > -- Christian Huitema > On 10/18/2022 8:49 PM, Hannes Tschofenig 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 *On Behalf Of * > Safe Browsing > *Sent:* Wednesday, October 19, 2022 4:56 AM > *To:* Eric Rescorla > *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 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 > 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 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
Re: [TLS] Securely disabling ECH
They seem to be operating reliably in numerous products/deployments though. Regardless, Nick brought my attention to Section 8.2, where proxies/middleboxes are not involved, but the same questions are elicited. Thanks, On Thu, Oct 20, 2022 at 12:34 AM Christian Huitema wrote: > So called "transparent" proxies relie on lies. The price of lies is of > course brittleness. Configured proxies could be made robust. > > -- Christian Huitema > > On Oct 19, 2022, at 5:55 PM, Safe Browsing > wrote: > > > Hi Christian, > > For transparent proxies, no. > > Thanks > > On Wed, Oct 19, 2022 at 4:51 AM Christian Huitema > wrote: > >> If one connects to a proxy, shouldn't the SNI point to the name of the >> proxy? >> >> -- Christian Huitema >> On 10/18/2022 8:49 PM, Hannes Tschofenig 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 *On Behalf Of * >> Safe Browsing >> *Sent:* Wednesday, October 19, 2022 4:56 AM >> *To:* Eric Rescorla >> *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 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 >> 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 we
Re: [TLS] Securely disabling ECH
I take your point about clients that may not implement the retry regardless of the spec. It is accepted that such a client would then not be able to make a connection through a security providing appliance. Which I suppose is the appropriate behaviour, since the appliance, being deployed for its security providing properties, would not be able to inspect the traffic for any malicious payload, and therefore the connection must be dropped. Yes, it would be good if the text in Section 6.1.6 could be clarified regarding the retry mechanism in this case. Something like this, from my previous email: "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 SHOULD retry the handshake with a new transport connection and ECH disabled." Thanks for your input. On Thu, Oct 20, 2022 at 12:41 AM Nick Harper wrote: > 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 > 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 &
Re: [TLS] Securely disabling ECH
Certainly, within the umbrella of "Network Security", privacy is a category. ECH falls into that category. As with many things in life there is also a trade-off that ECH brings along. More privacy, at possibly less "Network Security" (not a less secure TLS connection), as noted in some of the other emails. Thanks, On Thu, Oct 20, 2022 at 12:14 AM Salz, Rich wrote: > >- ECH is not a security feature per se. > > > > The ability of a third party to not be able to see who is communicating is > something that many would consider a security feature. Within the US > infosec community there was a great deal of uproar about NSA data > collection, even if it was “just” (sarcastic airquotes) metadata. Some may > disagree with that assessment, as you apparently do, but please don’t make > definitive statements like the above. > > > >- 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 > > > > The simplest way for an entity to disable ECH is to not have the DNS > records with the ECH keys. If that means that TLS-inspecting middleboxes > now need to also become DNS servers, many would say that is the cost of > interception. Many would probably also say that’s not a reasonable cost to > impose, but I expect them to be in the minority viewpoint at the IETF. > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
