Re: [TLS] DTLS 1.3 AEAD additional data

[Hanno Becker <[e-mail]>]

Hi Martin,

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).

You criticize that an implicit CID which is still included in the AAD requires state on the receiver when processing multiple records within a single datagram, which is true. I'm saying that the same holds for the PR 143 which adds the implicit CID to the AAD even if it's not in the header. In that sense, this (valid) issue exists on both cases.

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.

There is nothing subjective here: You cannot make full use of the compression features such as length omission independently of the underlying datagram layer, because you have to know that the record you're sending will be the last. So clearly sending is _harder_ if you have to decide on the header format already during record protection, while if you can protect the record on the basis of the logical header data alone, choice of header format and choice of packing into datagrams can be handled entirely independently.

> 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.

What exactly?

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.

So far, there hasn't been any substance to the claim that authenticating the logical header is a "bug" or "defect", while in (a)-(c) above I provide multiple reasons why it is in fact beneficial.

Cheers,
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.