Subject: [TLS] Two final DTLS 1.3 issues

From: "Christopher Wood" <[email-masked]>
Date: Wed, 05 Jan 2022 18:34:47 -0800

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 06 Jan 2022 14:18:11 +1100

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:
> - 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.
> 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. 
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jan 2022 19:33:02 -0800

On Wed, Jan 5, 2022 at 7:18 PM Martin Thomson <[email-masked]> wrote:

> 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

---

From: Christopher Wood <[email-masked]>
Date: Thu, 27 Jan 2022 08:37:28 -0800

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 <[email-masked]> wrote:
> 
> 
> 
> 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 seems like the note ought to say that the transcripts are separable by the version, no?
> 
> -Ekr
> 
>