Re: [TLS] DTLS 1.3 AEAD additional data

[Eric Rescorla <[e-mail]>]

On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson <[e-mail]> wrote:

> I prefer Ekr's solution, but I would go with that being a recommendation
> (SHOULD) as opposed to a requirement (MUST).
>

Can you clarify where you think we should say SHOULD?

-Ekr


> 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-mail]>
> > *Sent:* Wednesday, April 22, 2020 3:47 PM
> > *To:* Hanno Becker <[e-mail]>
> > *Cc:* [e-mail] <[e-mail]>
> > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data
> >
> >
> > 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 <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.
> >  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
> >
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>