Thanks for putting this together! I’m in favor of the mechanism and look forward to discussing it. Negotiating with signature_algorithms is a simple way to roll this out, it fits in cleanly with the key schedule, and the benefits outlined in the introduction (PRNG hardening, plausible deniability, etc.) seem worth the effort. Although the approach has its roots in OPTLS, we will certainly need to re-assess its impact on the handshake. (I know of some folks actively working on this.) We also need to spend more time thinking about the open issues — specifically, the story around early data encryption. This variant has the benefit of enabling early data with public key encryption, as opposed to (trackable) symmetric key encryption. It’s unclear to me whether or not we need to address the static share publication issue for this benefit.
Anyway, thanks again for the draft. I’ll read it carefully before London. Best, Chris On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla <e...@rtfm.com>, wrote: > Hi folks, > > Here's another entry in the DH-only pile. > > I've just posted: > draft-rescorla-tls13-semistatic-dh-00 > > This implements a semi-static DH exchange mostly borrowed from > OPTLS [0]. There are obviously connections with draft-putman, but > this is more oriented towards implementing a 1-RTT style > exchange where the client has no foreknowledge of the server's > capabilities (though it's extensible to 0-RTT) than towards > pre-distributed DH keys, and has less invasive changes to the > key schedule. > > We'd like 10 minutes to discuss this in London. > > Thanks, > -Ekr > > [0] http://ieeexplore.ieee.org/abstract/document/7467348/ > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
