Subject: [TLS] DTLS 1.3 AEAD additional data

From: Hanno Becker <[email-masked]>
Date: Tue, 21 Apr 2020 15:23:33 +0000

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.

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.

  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.

- 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.

  One might of course turn this argument around and say that
  such modifications are unwanted and using the header on-the-wire
  as the AEAD allows to detect them, but I don't yet see the
  concrete problem with them so far.

- 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.

- Uniformity with other [D]TLS versions

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Apr 2020 10:59:16 -0700

> of the record header instead, as do all other versions of [D]TLS as

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.

>   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.

>   and not distinguish between initial and non-initial records in

We're not distinguishing it. The AD is protecting the record on the wire.

- Modularity
>   to change the record header format in transit.

This seems like a defect, not a feature.

- Simplicity
>   avoided if record protection would use the structured

I've implemented this for QUIC (I can't remember who at Mozilla did it for
DTLS) and it's not particularly difficult.

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Apr 2020 18:23:22 -0700

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

---

From: Hanno Becker <[email-masked]>
Date: Wed, 22 Apr 2020 06:25:53 +0000

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 <[email-masked]>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data

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

-Ekr

On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

```

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.

```

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.

- Modularity

- Simplicity

I've implemented this for QUIC (I can't remember who at Mozilla did it for DTLS) and it's not particularly difficult.

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

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
[email-masked]<mailto:[email-masked]>
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.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Apr 2020 05:28:39 -0700

> perfectly acceptable to me to have implicit header data which is

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?

> moreover duplicates the CID in case it is explicitly present in the header.

Yes, so?

> 3. Compute AAD over logical presentation of record header.

The security principle we decided on for TLS 1.3 was that the AEAD should
cover what is
actually on the wire. I would be strongly opposed to going back on that.

-Ekr

-Ekr

> Hanno
> ------------------------------
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Wednesday, April 22, 2020 2:23 AM
> *To:* Hanno Becker <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data
>

---

From: Hanno Becker <[email-masked]>
Date: Wed, 22 Apr 2020 14:31:05 +0000

Hey Ekr,

The security principle we decided on for TLS 1.3 was that the AEAD should cover what is
actually on the wire. I would be strongly opposed to going back on that.

I don't think TLS 1.3 constitutes a precedent in either direction here, since the wire-format and the
logical representation are simply the same in TLS 1.3? A more comparable case seems to be cTLS,
where the current draft retains the logical presentation of the TLS 1.3 AAD, but omits the entire
record-header on the wire. cTLS is actually a good example:  You have a compression layer
which is orthogonal to the rest of the protocol (e.g. omitting HS data from the wire but
not the transcript, or omitting the record header from the wire but not the AAD), and
I think all the DTLS 1.3 header compression techniques should fall into the same category.

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.

Yes, so?

Isn't this less efficient 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?

Best,
Hanno

Looking forward to hearing other WG member's views,
Hanno
________________________________
From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data

-Ekr

```

```

- Modularity

- Simplicity

-Ekr

Best,
Hanno

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Apr 2020 07:47:10 -0700

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

> 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to
> RequestConnectionID with Ack;;NewConnectionId

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.

> 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

 I don't recall making that argument.

-Ekr

---

From: Hanno Becker <[email-masked]>
Date: Wed, 22 Apr 2020 16:23:23 +0000

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

Sent: Wednesday, April 22, 2020 3:47 PM

On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker <[email-masked]<mailto:[email-masked]>> wrote:

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.

Yes, so?

Trivially.

-Ekr

Best,
Hanno

-Ekr

```

```

- Modularity

- Simplicity

-Ekr

Best,
Hanno

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 09:53:59 +1000

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:
> *Sent:* Wednesday, April 22, 2020 3:47 PM
> 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.
> 
> 
> > 
> >> 2. Forbid implicit CIDs (my preference) see:  https://github.com/tlswg/dtls13-spec/issues/144 <https://github..com/tlswg/dtls13-spec/issues/144>
> >> 
> >>>>  octets long.. Note that this design is different from the additional
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you. 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 22 Apr 2020 17:00:17 -0700

(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.
> 
> 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
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Apr 2020 18:24:02 -0700

On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson <[email-masked]> 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

> 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.
>
> 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.
>
> 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
>
> https://github.com/tlswg/dtls13-spec/issues/144 <https://github.
> .com/tlswg/dtls13-spec/issues/144>
> > >>
> > >>> 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.
> > >>>
> > >>>
> > >>> 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.
> > >>>>
> > >>>>
> > >>> I've implemented this for QUIC (I can't remember who at Mozilla did
> it for DTLS) and it's not particularly difficult.
> > >>>
> > >>>
> > >>> 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
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>  IMPORTANT NOTICE: The contents of this email and any attachments
> are confidential and may also be privileged. If you are not the intended

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 11:39:01 +1000

> Can you clarify where you think we should say SHOULD?

The security considerations seems right.  After the list of improvements over DTLS 1.2 CID.  You would say that an endpoint that is asked to provide a CID SHOULD provide one in every record (with the compact header, etc...).  If it does not, then it might be possible for an attacker to use that record to confirm guesses about linkability between two paths.  Also, omitting the CID might make it hard to route datagrams.

With all of this, you might want a section heading for all the CID stuff.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Apr 2020 18:49:05 -0700

OK but we would expect the peer to process CID-less records if they are
coalesced?

-Ekr

On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson <[email-masked]> wrote:

> The security considerations seems right.  After the list of improvements
> over DTLS 1.2 CID.  You would say that an endpoint that is asked to provide
> a CID SHOULD provide one in every record (with the compact header,
> etc...).  If it does not, then it might be possible for an attacker to use
> that record to confirm guesses about linkability between two paths.  Also,
> omitting the CID might make it hard to route datagrams.
>

---

From: Hanno Becker <[email-masked]>
Date: Thu, 23 Apr 2020 06:43:23 +0000

Hey,

Thanks for joining in, Martin and Chris.

> 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 s…

Yes that's a fair point and also applies to Ekr's proposal https://github.com/tlswg/dtls13-spec/pull/143. Moreover,
the same layer-mixing criticism applies to the draft as it stands as well as to the other proposed solution, as mentioned before:
When you prepare a record, you need to know where it resides within a datagram in order to choose the best header and
AAD: You need to know if it's non-initial within the datagram to decide if you can omit the CID, and you need to know if
it's terminal to decide if you can omit the length.

In contrast, if you decouple the choice of header format from the AAD, record protection can be done prior to
passing the record to the datagram layer. As mentioned initially, this not only increases modularity within the
stack, but also allows e.g. to change the header towards more aggressive compression at the entry of a highly
constrained network, which I believe is indeed a feature and not a "defect" and increases suitability
of DTLS 1.3 for the IoT.

The CID maintenance for incoming records can be avoided when forbidding CID elision, as suggested by Ekr.
Comparing the state maintenance complications this avoids to the increase in header size it introduces, maybe
that's the way to go, as the state maintenance indeed seems to be the bigger pain.
However, even if CID elision is removed, I maintain the proposal to always use the logical presentation of the header
for AAD, for all the mentioned reasons: (a) No interleaving of record and datagram layer, (b) conceptual clarity and
independence of [header] compression methods from cryptographic computations, as e.g. in cTLS, (c) dynamic
choice of header depending on network paths. All those issues persist when sticking to the on-the-wire AAD.
What are your reservations towards this?

Cheers,
Hanno
________________________________
From: TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Thursday, April 23, 2020 2:49 AM
To: Martin Thomson <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data

OK but we would expect the peer to process CID-less records if they are coalesced?

-Ekr

On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 17:40:09 +1000

> OK but we would expect the peer to process CID-less records if they are 

I guess so.  If we allowed them to drop them, then we're close to saying MUST NOT omit.

On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> state transmission between records for good reasons. So this would be a 
> fairly bad complication. Separately, I hope that no one would be 
> Yes that's a fair point and also applies to Ekr's proposal 
> https://github.com/tlswg/dtls13-spec/pull/143. 

I don't see how.  If you are talking about marshaling costs, that's a constant problem, but we haven't found that to be an issue in practice.  From my perspective, it's the old DTLS records with a pseudo-header that are hard to construct; the new format is far easier to construct for sending (assuming that you don't try to shave the sequence number length down dynamically, but that's a new option our stack doesn't try to use).

Yours is a sending-side concern, and that seems to be subjective, because I think that sending is easier without a pseudo-header.  My concerns were about receiving.

> Comparing the state maintenance complications this avoids to the 
> increase in header size it introduces, maybe 
> However, even if CID elision is removed, I maintain the proposal to 
> always use the logical presentation of the header
> for AAD, for all the mentioned reasons: (a) No interleaving of record 
> and datagram layer, (b) conceptual clarity and 
> independence of [header] compression methods from cryptographic 
> computations, as e.g. in cTLS, (c) dynamic 

I'm sorry, I don't follow your argument.

The authenticated logical header being different than what is sent on the wire is a bug in my opinion.  Authenticating all the bytes you send makes the protocol simpler and less error prone.

---

From: Hanno Becker <[email-masked]>
Date: Thu, 23 Apr 2020 08:11:22 +0000

Hi Martin,

You criticize that an implicit CID which is still included in the AAD requires state on the receiver when processing multiple records within a single datagram, which is true. I'm saying that the same holds for the PR 143 which adds the implicit CID to the AAD even if it's not in the header. In that sense, this (valid) issue exists on both cases.

There is nothing subjective here: You cannot make full use of the compression features such as length omission independently of the underlying datagram layer, because you have to know that the record you're sending will be the last. So clearly sending is _harder_ if you have to decide on the header format already during record protection, while if you can protect the record on the basis of the logical header data alone, choice of header format and choice of packing into datagrams can be handled entirely independently.

What exactly?

So far, there hasn't been any substance to the claim that authenticating the logical header is a "bug" or "defect", while in (a)-(c) above I provide multiple reasons why it is in fact beneficial.

Cheers,
Hanno

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 18:25:57 +1000

On Thu, Apr 23, 2020, at 18:11, Hanno Becker wrote:
> You criticize that an implicit CID which is still included in the AAD 
> requires state on the receiver when processing multiple records within 
> a single datagram, which is true. I'm saying that the same holds for 
> the PR 143 which adds the implicit CID to the AAD even if it's not in 
> the header. In that sense, this (valid) issue exists on both cases. 

Right, but that is why I don't like 143..
 
> There is nothing subjective here: You cannot make full use of the 
> compression features such as length omission independently of the 
> underlying datagram layer, because you have to know that the record 
> you're sending will be the last. So clearly sending is _harder_ if you 
> have to decide on the header format already during record protection, 
> while if you can protect the record on the basis of the logical header 
> data alone, choice of header format and choice of packing into 
> datagrams can be handled entirely independently. 

Those are new, optional features, so I'm assuming that any costs associated with exercising them justify any complexity.

> So far, there hasn't been any substance to the claim that 
> authenticating the logical header is a "bug" or "defect", while in 
> (a)-(c) above I provide multiple reasons why it is in fact beneficial.

I don't agree with your reasoning.  As far as a bug, let me just say that having to allocate and construct a pseudo-header separate to the actual header is work that no longer has to be done.  So receiver logic is easier.

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 23 Apr 2020 12:00:03 +0000

Just one comment.

On 23/04/2020, 00:54, "Martin Thomson" <[email-masked]> wrote:
> a fairly bad complication.

The cost of keeping per-datagram state on the receiving end seem very
low to me.  And that would be the only cost overall, because on the
sending side there's none.  And this is in contrast to the higher sender
complexity in the current draft.  Also, once you start keeping
per-datagram state, you might as well stash as much as possible in it
and for example compress sequence numbers as well as just the CID.

So, if that is the only blocker WRT Hanno's proposal, I'd be happy to
trade that off for the nice properties it comes with.

> Separately, I hope that no one would be contemplating trial decryption
> for this, which would be terrible.

Surely not.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2020 14:17:50 -0700

> I guess so.  If we allowed them to drop them, then we're close to saying

Yeah, I would make three points

1. Allowing implicit CIDs is very recent (it was introduced in -34)
2. The CID specification explicitly prohibits it for DTLS 1.2.
3. I haven't really heard a very compelling argument for this and I note
that QUIC forbids it [and in fact has much worse problems when you mix
epochs because the long header is so long]

So, given that the simplest and most consistent thing is to simply forbid
it: can someone make an argument for why this is important to permit?

-Ekr

> I don't see how.  If you are talking about marshaling costs, that's a
> constant problem, but we haven't found that to be an issue in practice.
> From my perspective, it's the old DTLS records with a pseudo-header that
> are hard to construct; the new format is far easier to construct for
> sending (assuming that you don't try to shave the sequence number length
> down dynamically, but that's a new option our stack doesn't try to use).
>
> Yours is a sending-side concern, and that seems to be subjective, because
> I think that sending is easier without a pseudo-header.  My concerns were
> about receiving.
>
> The authenticated logical header being different than what is sent on the
> wire is a bug in my opinion.  Authenticating all the bytes you send makes
> the protocol simpler and less error prone.
>

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 24 Apr 2020 17:30:14 -0700

On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> 3. I haven't really heard a very compelling argument for this and I 
> note that QUIC forbids it [and in fact has much worse problems when you 
> mix epochs because the long header is so long]
> 
> So, given that the simplest and most consistent thing is to simply 
> forbid it: can someone make an argument for why this is important to 
> permit?

Thanks to everyone who participated in this thread so far! Given the points above, the chairs would like to hear arguments in favor of implicit CIDs. Absent substantial rationale, we'll assume rough consensus for explicit CIDs. 

Best,
Chris, on behalf of the chairs

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 25 Apr 2020 10:11:29 +0000

On 25/04/2020, 01:30, "Christopher Wood" <[email-masked]> wrote:
> > 2. The CID specification explicitly prohibits it for DTLS 1.2.  3. I
> > haven't really heard a very compelling argument for this and I note
> > that QUIC forbids it [and in fact has much worse problems when you
> Thanks to everyone who participated in this thread so far! Given the
> points above, the chairs would like to hear arguments in favor of
> implicit CIDs. Absent substantial rationale, we'll assume rough
> consensus for explicit CIDs.

Hi Chris, I think implicit CID needs to be considered in the wider scope
of unified_hdr compression, together with implicit length and shortened
epoch.  In particular, from Chris P's emails I understand that being
able to authenticate records' length is a core assumption in the
security proof of TLS.  Therefore leaving it out from DTLS AAD when it's
not in the header looks like a pretty bad idea.  If this is the case
(i.e. the fact that the wire image by itself is not sufficient input to
the AAD), then authenticating implicit CIDs should just come in the same
bundle.

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 25 Apr 2020 10:43:26 +0000

On 25/04/2020, 11:11, "Thomas Fossati" <[email-masked]> wrote:
> > > 2. The CID specification explicitly prohibits it for DTLS 1.2.  3.
> > > I haven't really heard a very compelling argument for this and I
> > > note that QUIC forbids it [and in fact has much worse problems
> > > when you mix epochs because the long header is so long]
> > >
> > > forbid it: can someone make an argument for why this is important
> > > to permit?
> >
> Hi Chris, I think implicit CID needs to be considered in the wider
> scope of unified_hdr compression, together with implicit length and
> shortened epoch.  In particular, from Chris P's emails I understand
> that being able to authenticate records' length is a core assumption
> in the security proof of TLS.  Therefore leaving it out from DTLS AAD
> when it's not in the header looks like a pretty bad idea.  If this is
> the case (i.e. the fact that the wire image by itself is not
> sufficient input to the AAD), then authenticating implicit CIDs should
> just come in the same bundle.

Sorry, scratch that for the moment - I had missed the most recent emails
on this thread :-(

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 26 Apr 2020 09:37:39 +0000

On 25/04/2020, 11:43, "Thomas Fossati" <[email-masked]> wrote:
> > > > 3. I haven't really heard a very compelling argument for this
> > > >    and I note that QUIC forbids it [and in fact has much worse
> > > >    problems when you mix epochs because the long header is so
> > > >    long]
> > > >
> > > > So, given that the simplest and most consistent thing is to
> > > > simply forbid it: can someone make an argument for why this is
> > > > important to permit?
> > >
> > > Thanks to everyone who participated in this thread so far! Given
> > > the points above, the chairs would like to hear arguments in favor
> > > of implicit CIDs. Absent substantial rationale, we'll assume rough
> > in the security proof of TLS.  Therefore leaving it out from DTLS
> > AAD when it's not in the header looks like a pretty bad idea.  If
> > this is the case (i.e. the fact that the wire image by itself is not
> > sufficient input to the AAD), then authenticating implicit CIDs
> > should just come in the same bundle.
>
> Sorry, scratch that for the moment - I had missed the most recent
> emails on this thread :-(

Back to this after having read and digested the parallel thread.

As it stands I don't think we have enough data to take an optimal
decision with respect to what needs to be input to the AAD.

I suggest we err on the side of caution and use a pseudo-header approach
where the pseudo-header equates the wire-header (except the epoch is in
full) when no compression is involved and otherwise includes all the
elided fields.

I also note that it'd be great if the formal verification community
could carve some time to look into the security of DTLS 1.3.  There is
certainly a lot of overlap with TLS and I guess substantial parts of the
modelling can be reused, but there are interesting differences (in
particular, around the tight knit between reliability and security
layers during handshake) that are unique to DTLS and likely deserve a
more careful look.

cheers!

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 26 Apr 2020 07:49:05 -0700

> layers during handshake) that are unique to DTLS and likely deserve a

Thanks, Thomas. To clarify (as the request was about prohibiting implicit CIDs and not more generally about what's included in the AAD), you'd prefer we allow implicit CIDs, correct? I agree that backing analysis would be generally useful here.

Best,
Chris

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 27 Apr 2020 11:32:26 +0000

On 26/04/2020, 15:49, "Christopher Wood" <[email-masked]> wrote:
> To clarify (as the request was about prohibiting implicit CIDs and not
> more generally about what's included in the AAD), you'd prefer we
> allow implicit CIDs, correct?

Hi Chris, correct.