Re: [TLS] Late DLS 1.3 issue

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