I've been thinking about this on and off.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: 08 March 2018 23:25
I think that this and draft-putman are not competing, but rather that they
serve different use cases
Agreed. It sounds like you have a set of use cases where you
static key which could later be used in a draft-putman
> > > exchange; however, the natural continuation would be to use a resumption
> > > PSK, so this would only be useful if there were a long gap between
> > > session, which seems unlikely.
> > >
:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Christopher Wood
> *Sent:* 07 March 2018 01:26
> *To:* ; Eric Rescorla
> *Subject:* Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS
> 1.3
>
>
>
> Thanks for putting this together! I’m in favor of the mechanism
on PSK, so this would only be useful if there were a long gap between
session, which seems unlikely.
Regards,
Tony
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Christopher Wood
Sent: 07 March 2018 01:26
To: ; Eric Rescorla
Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment f
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 deniabilit
