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... > 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
