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?
What if we kept the ClientHelloInner...ServerHelloECHConf transcript as in the current draft, but derived the signal exclusively from that? (Or from the client random and that transcript, though the transcript includes the client random anyway.) We'll still bind in the ServerHello extensions, and it still includes the encrypted inner ClientHello random, as in the randoms formulation. It doesn't do the job as clearly as the handshake secret did, but maybe it'll work? Implementation-wise, this variant would not require actually processing the ServerHello extensions.
Right - if that's ok security-wise then it'd be fine for implementation, better than either the current approach or full trial decryption. We could I suppose consider just keeping the current expand/extract construct but replacing the handshake-secret with something else based just on that same input buffer. Cheers, S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
