These are both disruptive changes, but I agree that they are OK in principle.
I have a few questions on #257. Those are on the PR, but I'll repeat them here: Many implementations of DTLS use a 16-bit integer to hold epoch. Sometimes, that leaks into places that mean that it is hard to change. Those of us with this problem can probably pull the same trick as here and only expose the low 16 bits, but would it be possible to implement this without allowing key updates that take epoch to 2^16? If the epoch can have 64 bit values, then why not allow for the full range of values to be used? Is there an analysis that suggests that rekeying too often leads to this problem? (Similarly, the 2^48 limit on the sequence number makes little sense in this context.) It would be good to highlight the fact that #262 can result in transcript collisions between DTLS and TLS (with the exception of maybe supported_versions because we're now using the inverted encoding ...for no good reason? or for this specific reason?). However, even though the transcript that is input to HKDF might be the same, true problems arising from a collision are avoided because all key derivations use a different label with HKDF. That means that we depend on using HKDF-Expand-Label for key diversity between DTLS and TLS, so any use of keys in either protocol has to pass through at least one invocation of that function. Only the early secret doesn't meet this condition, so I'm not worried, but it needs to be noted (and it isn't). On Thu, Jan 6, 2022, at 13:34, Christopher Wood wrote: > Hi folks, > > As discussed during IETF 112, there are two outstanding DTLS 1.3 issues > with proposed resolutions: > > - https://github.com/tlswg/dtls13-spec/pull/257: This resolves the > epoch limit issue. It received external review from cryptographers and > the authors have confidence in the change. > - https://github.com/tlswg/dtls13-spec/pull/262: This aligns the DTLS > 1.3 transcript with that of TLS 1.3. > > We'd like to run a brief consensus call on these proposed resolutions. > Please chime in if you'd like to see changes of any kind. Absent > objections, we'll merge them and proceed with the remaining RPC edits. > > This call will close on Friday, January 14. > > Best, > Chris, for the chairs > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
