Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?

[Christian Huitema <[e-mail]>]

On 3/19/2021 2:58 PM, David Benjamin wrote:
> On Thu, Mar 18, 2021 at 4:07 PM Stephen Farrell<[e-mail]>
> wrote:
>
>> Hiya,
>>
>> On 18/03/2021 19:17, David Benjamin wrote:
>>> I don't think I'd agree that*most*  of the work is in the secret
>>   > computation per se. Actually doing trial decryption with
>>   > the secret requires reaching down into the record layer.
>>   > This is especially onerous for QUIC, where the record layer
>>   > is offloaded to another protocol (often outside the TLS
>>   > library).
>>
>> Ah, fair point - I've not looked at QUIC at all. But how
>> are encrypted extensions and tickets handled in such cases?
>> If those are handled in the original library then a trial
>> decryption should be possible too maybe?
>>
> QUIC replaces the record layer and keeps the TLS handshake. So as the TLS
> handshake progresses, it hands keys (handshake traffic keys, etc.), to
> QUIC to install. When TLS needs to write an EncryptedExtensions or so, it
> hands QUIC cleartext to encrypt. When QUIC decrypts a record and sees a
> CRYPTO frame, it hands the results to TLS to process as handshake messages.
> The draft is here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-tls/
>
> In all the stacks I'm aware of, there are QUIC-specific APIs to install a
> custom record layer of sorts. And thus the nuisance with trial decryption
> and friends. Every new feature we push down to the record layer changes
> that record layer interface. This means more coordination between QUIC and
> TLS. Something like trial decryption would require TLS hand QUIC both sets
> of handshake keys. Then QUIC would need to do the trial decryption and
> report back to TLS which set of keys won.
>
> (If you're working on an OpenSSL ECH implementation, you probably won't see
> this because OpenSSL doesn't have APIs for QUIC yet.)

That, or try race two connection contexts corresponding to the two 
trials, and keep the first that succeeds. Which would indeed require TLS 
to tell QUIC that "the key might be K1 or K2". That's also very 
complicated. For the QUIC client, the current text is much better.

Let's come back to the original discussion. If I look back at the 
discussion of issue 274 
(https://github.com/tlswg/draft-ietf-tls-esni/issues/274), we ended up 
at some point with a set of alternatives, including these two:

     * accept_confirmation = PRF(ClientHelloInner.random, 
ServerHello.random[0:24])
     * accept_confirmation = PRF(ClientHelloInner.random, 
ServerHello.KeyShare)

The issue was closed by PR #287 
(https://github.com/tlswg/draft-ietf-tls-esni/pull/287/files) which 
selected the first of these two options. But this was later updated by 
PR #353 (https://github.com/tlswg/draft-ietf-tls-esni/pull/353), which 
changed that to the second option, the one including the server key 
share. The correction allows mitigating an attack in which the 
interceptor copies the server hello but substitutes its own key share, 
and thus can test whether ECH was used.

Look at the comment, "This change is definitely more invasive than the 
existing signal, but not all that hard to implement. (E.g., 
cloudflare/go#38 <https://github.com/cloudflare/go/pull/38>.)" later in 
the thread.

We do have new information that this is somewhat costly to implement 
because it requires computing two handshake secrets on the client. On 
the other hand, it seems that the cost is only there if the client 
starts by testing the wrong hypothesis. If the client is fairly certain 
that the server supports ECH, the CPU overhead ought to be minimal -- 
cases in which the client is using the wrong ECH key, or when an 
interceptor interfered with the exchange.

-- Christian Huitema