Re: [TLS] DTLS 1.3 AEAD additional data

[Eric Rescorla <[e-mail]>]

On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson <[e-mail]> wrote:

> On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> > OK but we would expect the peer to process CID-less records if they are
> > coalesced?
>
> I guess so.  If we allowed them to drop them, then we're close to saying
> MUST NOT omit.
>

Yeah, I would make three points

1. Allowing implicit CIDs is very recent (it was introduced in -34)
2. The CID specification explicitly prohibits it for DTLS 1.2.
3. I haven't really heard a very compelling argument for this and I note
that QUIC forbids it [and in fact has much worse problems when you mix
epochs because the long header is so long]

So, given that the simplest and most consistent thing is to simply forbid
it: can someone make an argument for why this is important to permit?

-Ekr


> On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> >  > But Hanno's proposal is a terrible thing to have to implement. You
> > have to assume that there is some way to recover which CID to use in
> > decrypting any record. You might save some datagram-local state, but
> > that's awkward. Stacks that I've worked on try very hard not to have
> > state transmission between records for good reasons. So this would be a
> > fairly bad complication. Separately, I hope that no one would be
> > contemplating trial decryption for this, which would be terrible.
> >
> > Yes that's a fair point and also applies to Ekr's proposal
> > https://github.com/tlswg/dtls13-spec/pull/143.
>
> I don't see how.  If you are talking about marshaling costs, that's a
> constant problem, but we haven't found that to be an issue in practice.
> From my perspective, it's the old DTLS records with a pseudo-header that
> are hard to construct; the new format is far easier to construct for
> sending (assuming that you don't try to shave the sequence number length
> down dynamically, but that's a new option our stack doesn't try to use).
>
> Yours is a sending-side concern, and that seems to be subjective, because
> I think that sending is easier without a pseudo-header.  My concerns were
> about receiving.
>
> > The CID maintenance for incoming records can be avoided when forbidding
> > CID elision, as suggested by Ekr.
> > Comparing the state maintenance complications this avoids to the
> > increase in header size it introduces, maybe
> > that's the way to go, as the state maintenance indeed seems to be the
> > bigger pain.
> > However, even if CID elision is removed, I maintain the proposal to
> > always use the logical presentation of the header
> > for AAD, for all the mentioned reasons: (a) No interleaving of record
> > and datagram layer, (b) conceptual clarity and
> > independence of [header] compression methods from cryptographic
> > computations, as e.g. in cTLS, (c) dynamic
> > choice of header depending on network paths. All those issues persist
> > when sticking to the on-the-wire AAD.
> > What are your reservations towards this?
>
> I'm sorry, I don't follow your argument.
>
> The authenticated logical header being different than what is sent on the
> wire is a bug in my opinion.  Authenticating all the bytes you send makes
> the protocol simpler and less error prone.
>