Re: [TLS] Late DLS 1.3 issue

[Ilari Liusvaara <[e-mail]>]

On Tue, Oct 05, 2021 at 06:58:24PM -0700, Eric Rescorla wrote:
> On Tue, Oct 5, 2021 at 6:36 PM Martin Thomson <[e-mail]> wrote:
> 
> > 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.
> >
> 
> This isn't dispositive, but note that TLS 1.3 doesn't include the epoch in
> its nonce at all.

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