On Tue, Oct 05, 2021 at 06:58:24PM -0700, Eric Rescorla wrote: > On Tue, Oct 5, 2021 at 6:36 PM Martin Thomson <m...@lowentropy.net> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
