Subject: [TLS] Late DLS 1.3 issue

From: "Christopher Wood" <[email-masked]>
Date: Tue, 05 Oct 2021 16:14:49 -0700

Hi folks,

There's one late breaking issue we need to resolve for DTLS 1.3 before it proceeds to publication:

   https://github.com/tlswg/dtls13-spec/issues/249

Based on discussions with some people involved in the security analysis of TLS 1.3, a proposed fix is here:

   https://github.com/tlswg/dtls13-spec/pull/255

We'd like to merge this to resolve the issue and continue forward progress. To that end, please review the issue and change and indicate whether or not it is workable for you. Barring objections, we'll merge the PR on Friday, October 15. 

Best,
Chris, for the chairs

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Oct 2021 12:34:50 +1100

I left a comment, but I don't think that the fix, as it is specifically proposed, works.

The general shape of the proposal seems credible.  A larger epoch space, of which we only send the least-significant bits, would seem to address the concern.  But the proposal doesn't specify what to do with the per-record nonce.

If we go with a 48-bit epoch we get a few more records (2^32 times as many I suppose), which is probably enough.  And the value would fit in the per-record nonce.  Then you just need a bunch more text that explains how to encode that nonce.

A 64-bit epoch doesn't fit in any nonce we currently use.  We could truncate, which would need more analysis (my intuition is that it would be OK, but I'd like more than a gut feeling).  We might use the expanded nonce options that some (not all) AEAD ciphers have, but that would be a very bad idea.

Anyhow, this is all independent of how annoying this will be to implement.  This change is likely to be VERY disruptive to our implementation.  From memory, we have exposed an epoch size through interfaces that we can't change.  Has anyone looked at making the proposed changes in a serious implementation?

On Wed, Oct 6, 2021, at 10:14, Christopher Wood wrote:
> We'd like to merge this to resolve the issue and continue forward 
> progress. To that end, please review the issue and change and indicate 
> whether or not it is workable for you. Barring objections, we'll merge 
> the PR on Friday, October 15. 
>
> Best,
> Chris, for the chairs
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Oct 2021 18:58:24 -0700

On Tue, Oct 5, 2021 at 6:36 PM Martin Thomson <[email-masked]> wrote:

> The general shape of the proposal seems credible.  A larger epoch space,
> of which we only send the least-significant bits, would seem to address the
> concern.  But the proposal doesn't specify what to do with the per-record
> nonce.
>
> If we go with a 48-bit epoch we get a few more records (2^32 times as many
> I suppose), which is probably enough.  And the value would fit in the
> per-record nonce.  Then you just need a bunch more text that explains how
> to encode that nonce.
>
> A 64-bit epoch doesn't fit in any nonce we currently use.  We could
> truncate, which would need more analysis (my intuition is that it would be
> OK, but I'd like more than a gut feeling).  We might use the expanded nonce
> options that some (not all) AEAD ciphers have, but that would be a very bad
> idea.
>

This isn't dispositive, but note that TLS 1.3 doesn't include the epoch in
its nonce at all.

-Ekr

> Anyhow, this is all independent of how annoying this will be to
> implement.  This change is likely to be VERY disruptive to our
> implementation.  From memory, we have exposed an epoch size through
> interfaces that we can't change.  Has anyone looked at making the proposed
> changes in a serious implementation?
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Oct 2021 14:36:23 +1100

On Wed, Oct 6, 2021, at 12:58, Eric Rescorla wrote:
> This isn't dispositive, but note that TLS 1.3 doesn't include the epoch 
> in its nonce at all. 

That strengthens the gut instinct some, as does the fact that QUIC doesn't either.  But neither of those protocols is exactly the same as DTLS.  DTLS doesn't place a hard end on any given epoch.  TLS does.  QUIC's continuous packet number space creates a hard limit, even if that limit isn't a single value.  That suggests that some analysis would be helpful.

I'm less concerned about analysis than I am about getting the specification bit right.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Oct 2021 14:43:39 +0300

> This isn't dispositive, but note that TLS 1.3 doesn't include the epoch in

The way I read editor's copy (section 4), DTLS 1.3 does stick the
(64-bit!) epoch in nonce, Which does not work at all with
Chacha20-Poly1305-AEAD, and would need AES-GCM with expanded nonce,
which is poorly suppored and IIRC cryptographically busted. 

Because DTLS 1.3 ratchets keys when switching epochs, it is not
necressary to include epoch in nonce. Just allowing epochs to wrap
around would not create cryptographic problems. It seems that it would
not cause problems with ACKs either:

Burning through the 65536 epochs will presumably either require insane
rekeying rate, or take so long that all potentially confusable ACK-
elicting packets and ACKs have been permanently lost. Badly timed
rehandshake could reuse epoch much faster than that, but it is not
possible to confuse such ACKs as any wrong ACKs are undecryptable.

-Ilari

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 06 Oct 2021 16:30:39 -0700

On Tue, Oct 5, 2021, at 8:36 PM, Martin Thomson wrote:
> That strengthens the gut instinct some, as does the fact that QUIC 
> doesn't either.  But neither of those protocols is exactly the same as 
> DTLS.  DTLS doesn't place a hard end on any given epoch.  TLS does.  
> QUIC's continuous packet number space creates a hard limit, even if 
> that limit isn't a single value.  That suggests that some analysis 
> would be helpful.
>

FWIW, the intent of the change was to indeed truncate the epoch, as this is the variant that seems safest. I think you caught a couple places where that wasn't captured quite right, which we can fix.

Best,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 14 Oct 2021 15:53:14 -0700

The PR's been updated to correct the editorial bug and clarify that the epoch is truncated. We could also go with Martin's suggestion to make the epoch 48 bits, yielding a 96-bit per-record sequence number. Or something else.

Please have another look. 

Thanks,
Chris

On Wed, Oct 6, 2021, at 4:30 PM, Christopher Wood wrote:
> FWIW, the intent of the change was to indeed truncate the epoch, as 
> this is the variant that seems safest. I think you caught a couple 
> places where that wasn't captured quite right, which we can fix.
>
> Best,
> Chris
>