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

[David Benjamin <[e-mail]>]

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

David