On Wed, Aug 03, 2016 at 08:30:22AM -0700, Eric Rescorla wrote: > Folks, > > As promised, I've written a PR that describes the new negotiation > syntax we discussed in Berlin. I also have prototype implementation of > this in NSS and it's quite a bit cleaner than the previous negotiation > design. I think that others have found the same thing.
Yup, looks much cleaner. > https://github.com/tlswg/tls13-spec/pull/559 > > IMPORTANT: This new negotiation syntax allows for two modes that were > not previously available with TLS 1.3: PSK and PSK-(EC)DHE with > server-side signatures. This construction should be safe with > resumption-PSK (this is why we introduced the resumption_ctx design), > but as noted in Antoine's recent message [0], this is not safe with > non-resumption PSK with the all-zeroes resumption context that we now > use with external PSKs. I have an action item to fix that, so just > keep that in the back of your head as you review this PR. The idea is to essentially use "resumption master secret" as PSK and then to derive the two subkeys off that on handshake, right? Also I noticed that now there is no indication on if the group indication in HRR is valid or not (pure-PSK). Dirty hack would be to grab some reserved value (FF01?) for "I don't need any more groups" (which isn't the same as "no group"). Or perhaps one could stick it into extension[1]. Also, now that there are signatures even with 0-RTT, one should recheck the 0-RTT extension checking logic (the original logic is now invalid, but I think conclusions[2] for free certificate case are still valid). However, if the thing does not use free certificates (in which case the logic should absolutely be specified, or one WILL get massive interop problems!) the conclusions definitely are not valid.. [1] One design would be to move group to extensions, rename 'extensions' to something like 'problems'. Then require 'problems' to be non-empty and require clients to abort if they see problem types they don't recognize (but problem types don't need to be advertized). [2] The original conclusions were that out of extensions, only server_name and application_layer_protocol_negotiation matter. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
