On Thu, Mar 18, 2021 at 4:07 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
