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
