Re: [TLS] Securely disabling ECH

[Safe Browsing <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> wrote:
>>
>>>
>>>
>>> On Tue, Oct 18, 2022 at 8:56 PM Safe Browsing <[e-mail]>
>>> 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-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>