(no hat) A SHOULD is probably fine provided we document the possible implications and consequences of not abiding by it. And Martin laid out a number of them below.
Best, Chris On Wed, Apr 22, 2020, at 4:53 PM, Martin Thomson wrote: > I prefer Ekr's solution, but I would go with that being a > recommendation (SHOULD) as opposed to a requirement (MUST). > > I was initially inclined toward doing nothing at all, but there is an > attack of sorts that is worth avoiding here. > > Say that a connection spans two network paths. CID A is used on path > A; CID B is used on path B. Let's assume that you need a connection ID > to route (otherwise, why bother), but that the first record in each > datagram is all that is needed for that purpose. > > The linkabliity confirmation attack allows an attacker that > hypothesizes a correlation between CID A and CID Bto confirm that > hypothesis. It relies on side channel leakage from endpoints, but as > this only involves measuring application reactions, I'm going to assume > that it is feasible to extract some signal. > > If an endpoint sends a datagram on path A that contains two records > where the second record omits the connection ID, then an attacker can > strip that second record out and copy it into a datagram sent on path > B. With the current design, the receiver accepts that packet and maybe > leaks some signal to the attacker that CID A and CID B really are the > same connection. With Hanno's proposed fix, the receiver of that > record will guess incorrectly that the datagram is bad and drop it, > providing no signal about the relationship between the two CIDs. > > 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. > > So I'm inclined toward cautioning against omitting the connection ID > when one is used. > > DTLS 1.3 already has fairly lightweight requirements around how > linkability is avoided. Activity on new paths does not strictly > require the use of a different CID, it's just a recommendation. > Allowing endpoints to omit a CID is consistent with that, even if we > don't recommend that. However, we do need to be careful to explain > this risk so that people are aware of the consequences of omission. > > I would also point out that we attempt to avoid creating correlators so > that attackers can't create hypotheses about linkability. Allowing > confirmation of a hypothesis is not that bad when the existence of the > hypothesis is itself what we are trying to avoid. Given the relative > cost of performing this attack to other means of confirming the > hypothesis - dropping packets and observing the response would be much > easier in many cases - I don't think that this warrants a strong > response. > > Cheers, > Martin > > On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote: > > Hi Ekr, > > > > I still don't yet understand which concrete problems you see with > > the proposed solution. In particular, as mentioned in the last mail, I > > don't think there > > is a contradiction with any design choice for TLS 1.3 - in contrast, > > decoupling > > record header compression from record protection aligns with how cTLS > > proposes to compress TLS 1.3 without affecting any cryptographic > > computations > > and hence hopefully easing carrying over the security analysis of TLS > > 1.3. This decoupling > > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that > > in the case of CIDs, > > it has already led to one missing cryptographic binding. > > > > Anyway, let's wait for more opinions. > > > > Best, > > Hanno > > > > *From:* Eric Rescorla <e...@rtfm.com> > > *Sent:* Wednesday, April 22, 2020 3:47 PM > > *To:* Hanno Becker <hanno.bec...@arm.com> > > *Cc:* tls@ietf.org <tls@ietf.org> > > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > > > > > On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker <hanno.bec...@arm.com> 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...@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 > > >> <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 > > >> 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. > > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
