Apologies for the delay here. The consensus call for these two issues is
complete. Based on the discussion below, the chairs will work with the editors
to address Martin’s feedback — which does not appear to be a blocker — before
getting this back in the RPC editor’s queue. (Martin, please let us know if we
misinterpreted your feedback.)
Thanks, all!
Best,
Chris, for the chairs
> On Jan 5, 2022, at 7:33 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
>
> On Wed, Jan 5, 2022 at 7:18 PM Martin Thomson <m...@lowentropy.net> wrote:
> 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?
>
> As noted in the PR, if you rekey on the order of 2^64 times you run a
> significant risk of collisions in the key. The randomized IV is intended to
> ameliorate this, but I prefer to be safe, especially as there is no plausible
> scenario in which you would need to do 2^{48} rekeys.
>
>
> (Similarly, the 2^48 limit on the sequence number makes little sense in
> this context.)
>
> Agreed. That's just holdover from the combined sequence number. I didn't
> realized I had missed it. Can you point to the relevant location and I'll fix.
>
>
> 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?).
>
> Well, in part for this reason, yes.
>
>
> 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).
>
> It seems like the note ought to say that the transcripts are separable by the
> version, no?
>
> -Ekr
>
>
> 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
> _______________________________________________
> 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
