Kyle Rose wrote: > On Mon, Nov 27, 2017 at 11:11 PM, Daniel B Giffin <d...@scs.stanford.edu> > wrote: > > Whether or not we decide to go back to the WG to discuss the > > mechanics of session resumption, we could make lightweight > > changes to the current protocol in this last call that would > > facilitate any "upgrades" that appear necessary after > > deployment has begun. > > > > To wit, we propose: > > > > - Replace the first byte of INIT1_MAGIC and INIT2_MAGIC > > with a "version" byte. Implementations of the current > > protocol must send a zero version-byte, and must ignore > > what they receive. > > > > - When receiving ENO suboptions for tcpcrypt TEPs with > > v=1, which are "resumption suboptions": if the > > resumption identifier-half is not the expected length > > (9 bytes), treat this suboption as a bare TEP byte with > > v=0; that is, an invitation to fresh key-exchange with > > that TEP. This *almost* goes without saying; the > > current draft doesn't say what to do in this case of > > "malformatted" resumption identifiers. > > Upon reflection, isn't this an oversight? It seems the draft should > address this regardless of how we decide to deal with misuse > tolerance.
Yes. It makes sense that whenever you send a TEP identifier (by itself or for resumption, even if you use some yet-unspecified resumption-request format), you are willing to do fresh key exchange with that TEP. Thus I have added this to section 3.5. Session Resumption: If a passive opener receives an ENO suboption with a TEP identifier and "v = 1", but the suboption data does not have length 9 bytes, it MUST behave as if the same TEP had been sent with "v = 0". That is, the suboption MUST be interpreted as an offer to negotiate fresh key exchange with that TEP. > > > The version byte is intended to allow implementations of > > future protocol versions to identify each other (by sending > > the highest version they support), which then allows them to > > perform "advanced" resumption signaling later. > > So is the idea that the format of INIT*_MAGIC would be fixed, and that > the version can only affect subsequent messages? I suppose the > alternative is that we burn a new set of TEPs whenever anything about > the protocol changes, so putting that extensibility directly into > tcpcrypt (where a much less constrained number of signaling bits are > available) makes sense for future proofing, maybe even irrespective of > this particular issue. I'm thinking of some analogy to ClientHello > extensions in TLS, where you can send stuff that the server might not > parse, and that's okay. Do we want an extra frame in/after the INIT > messages for sending version-specific data on the first flight that > old receiver versions will simply ignore (beyond including it in the > handshake transcript), to avoid an extra RTT for version negotiation? Because the new "version" byte would be the first byte sent in each direction, it can be used to negotiate any future protocol behavior to follow that byte. Even without the version byte, the Init1/Init2 messages already reserve trailing space for future uses, which implementations of the current protocol are instructed to ignore (although it is always part of the transcript). > > Kyle daniel _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
