On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > > > > An additional nice point about this design is that it easily > > accomodates additional keys. For instance, if we had some post-quantum > > key exchange method, we could easily add its key in the final > > Add-Secret or add an extra Add-Secret stage before HS. Similarly, if > > we had a long-term DH key as in OPTLSv1, it could replace the 0 in the > > final Add-Secret. > > Just one thing to be careful of: If one has off-handshake counter- > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash > those in, or one gets all kinds of crypto screw (which may or may not > be actually exploitable...) > > The "context identifier" looks real handy for that purpose.. Yep. We were thinking that too! Thanks for the quick look. -Ekr > > > CONTEXT IDENTIFIER > > > > The resumption_psk is then used as the PSK for resumption and the > > resumption_context is added to the hash of the handshake messages > > whenever you use them, currently just by appending to the hash, as in: > > > > Hash(handshake messages) +resumption_context > > > > This is used *both* to derive the keys and for the input to > > the CertificateVerify/Finished. For convenience, I've > > Oh, even better than the original "contexts" proposal, as this is > non-checked. As said, if you ever need off-handshake counterkeys > (as above, and you most probably do for adding any sort of realistic > post-quantum capabilities[2]), this looks real handy for mixing those > in. > > > [1] Any server-side key that isn't explicitly sent as part of the hand- > shake (most probably having been sent before in prior handshake) but > still is involved in the handshake. > > [2] There does exist PQ Key Agreement, but it currently just provoded by > one system that is relatively slow (through not completely impractical) > and severly underanalyzed (major problem). > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls