Re: [TLS] Securely disabling ECH

[Nick Harper <[e-mail]>]

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
>>>
>>