Re: [TLS] DTLS 1.3 AEAD additional data

[Eric Rescorla <[e-mail]>]

On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker <[e-mail]> wrote:

>
> Considering the effort spent on shaving off bytes in the DTLS header,
>
> I think re-introducing the explicit CID should be avoided. It seems
>
> perfectly acceptable to me to have implicit header data which is
>
> protected via AAD.
>
>
> This is only relevant if there is a common useful case in which you would
> need to put multiple
> DTLS records in the same datagram. Are you aware of such a case?
>
>
> I can see the following uses:
> 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to
> RequestConnectionID with Ack;;NewConnectionId
> 2) Sending multiple (short) app records if the application protocol
> doesn't provide its own framing.
>

Neither of these seem particularly compelling to me. The first happens very
infrequently, and I'm not really aware of a lot of cases of the second.



> > 1. Cryptographically protect it as in
> https://github.com/tlswg/dtls13-spec/pull/143
>
>
> This seems to be a mixture of logical and on-the-wire representation, which
>
> moreover duplicates the CID in case it is explicitly present in the header.
>
>
> Yes, so?
>
>
> Isn't this less efficient
>

Trivially.


and undoes the arguable benefit of the current solution that there's
> no need to piece together an AAD buffer manually, because now you'd have
> to?
>

 I don't recall making that argument.

-Ekr


> Best,
> Hanno
>
>
> Looking forward to hearing other WG member's views,
> Hanno
> ------------------------------
> *From:* Eric Rescorla <[e-mail]>
> *Sent:* Wednesday, April 22, 2020 2:23 AM
> *To:* Hanno Becker <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data
>
> I think there are two potential resolutions to your CID issue:
>
> 1. Cryptographically protect it as in
> https://github.com/tlswg/dtls13-spec/pull/143
> 2. Forbid implicit CIDs (my preference) see:
> https://github.com/tlswg/dtls13-spec/issues/144
>
> Would like to hear what others in the WG think.
>
> -Ekr
>
>
> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <[e-mail]> wrote:
>
> Hi all,
>
> To my understanding, DTLS 1.3 defines AEAD additional data for record
> protection
> as the record header as seen on the wire. Quoting Draft 37, Section 4:
>
> ```
>    The entire header value shown in Figure 4 (but prior to record number
>    encryption) is used as as the additional data value for the AEAD
>    function.  For instance, if the minimal variant is used, the AAD is 2
>    octets long.  Note that this design is different from the additional
>    data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
> ```
>
> I would like to suggest that DTLS 1.3 uses a structured representation
> of the record header instead, as do all other versions of [D]TLS as
> far as I understand.
>
>
> I am not in favor of this change as proposed. I think it is better to
> protect the data that is actually on the wire than to allow for changes in
> the on-the-wire representation that are not reflected in the integrity
> check.
>
>
> The reasons for this are as follows, in decreasing order of
> my perception of importance:
>
> - Omission of Connection ID
>
>   Regarding the presence of Connection IDs in multiple records within
>   a single datagram, Draft 37 says:
>
> ```
>    Implementations which send multiple records in the same datagram
>    SHOULD omit the connection id from all but the first record;
>    receiving implementations MUST assume that any subsequent records
>    without connection IDs belong to the same assocatiation.
> ```
>
>   This means that the Connection ID for non-initial records in a
>   datagram containing multiple records is _not_ part of the AEAD
>   additional data for those records, which seems wrong. Concretely,
>   one could inject such non-initial records into other datagrams
>   using different CIDs, and the record protection wouldn't notice it.
>
>
> This seems like a reasonable point, though it's not clear to me that there
> is an actual problem here. I'd be in favor of explicitly including the CID
> in the AD as well as the header.
>
>
>
>   One might argue that CID shouldn't be part of the AEAD in the first
>   place, but in any case, I believe the treatment should be uniform
>   and not distinguish between initial and non-initial records in
>   a datagram.
>
>
> We're not distinguishing it. The AD is protecting the record on the wire.
>
>
> - Modularity
>
>   Decoupling the wire-presentation of the record header from
>   record protection allows to implement record protection and
>   the choice of record header independently: One piece of
>   the implementation can take care of record protection -
>   using the structured presentation of the record header - while
>   another takes care of the wire-encoding. It is even possible
>   to change the record header format in transit.
>
>
> This seems like a defect, not a feature.
>
>
> - Simplicity
>
>   At first it seems that using the record header as an
>   unstructured binary blob for AEAD makes things simpler,
>   but I don't think this is the case: Prior to record
>   decryption, the record sequence number needs to be
>   decrypted, and for that purpose, the record header already
>   has to be parsed. Hence, at the time of record decryption,
>   the record header is already be present a modified, structured
>   form, and retaining the corresponding modified binary form
>   appears to create additional complexity which would be
>   avoided if record protection would use the structured
>   header presentation.
>
>
> I've implemented this for QUIC (I can't remember who at Mozilla did it for
> DTLS) and it's not particularly difficult.
>
>
> - Uniformity with other [D]TLS versions
>
>
> I don't find this argument at all persuasive. To the contrary: we should
> break with  DTLS 1.2 in any case where it's an improvement and not too
> onerous.
>
> -Ekr
>
>
>
>
> Let me know what you think,
>
> Best,
> 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.
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
> 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.
>
> 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.
>