Hi Ekr, > 2. Forbid implicit CIDs (my preference) see: > https://github.com/tlswg/dtls13-spec/issues/144
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. Moreover, coming back to protecting the logical header and not the on-the-wire header and hence allowing header compression after protection, I still consider this a feature and not a defect, and the CID elision is actually a useful example for this: The record protection layer can emit protected records regardless of how they are packed into datagrams, and the part of the code responsible for the latter is free to remove CIDs from the headers of non-initial records in case it fits more than one records into a single datagram. In contrast, requiring the record layer to know how the record will be placed into a datagram interleaves different layers and introduces unnecessary dependency and complexity. (The omission of the total record length is actually another example for this: It should be the datagram layer, not the record layer, which decides whether the length needs to be explicit in the header or not). > 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. I uphold my preference for an entirely structured presentation of the header as AAD instead of the binary data and think it should be added to the list of options: 3. Compute AAD over logical presentation of record header. Looking forward to hearing other WG member's views, Hanno ________________________________ From: Eric Rescorla <e...@rtfm.com> Sent: Wednesday, April 22, 2020 2:23 AM To: Hanno Becker <hanno.bec...@arm.com> Cc: tls@ietf.org <tls@ietf.org> 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...@rtfm.com<mailto:e...@rtfm.com>> wrote: On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <hanno.bec...@arm.com<mailto:hanno.bec...@arm.com>> 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 TLS@ietf.org<mailto:TLS@ietf.org> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
