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.


On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla <>, 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]
> _______________________________________________
> TLS mailing list
TLS mailing list

Reply via email to