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> wrote: > > > On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <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 >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
