Re: [TLS] DTLS 1.3 AEAD additional data

[Martin Thomson <[e-mail]>]

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.

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.