Subject: [TLS] Choice of Additional Data Computation

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Apr 2020 11:04:06 +0000

Hi all,

the thread on the AEAD commutation in DTLS 1.3 and the construction of the additional data raised two interesting questions. I believe those would benefit from a formal analysis or at least a security investigation.

Here are the questions:

  1.  Generic question: Should the construction of the additional data be dependent on what is transmitted over the wire or should it be based on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the data transmitted over the wire in the additional data calculation.
  2.  Specific question: Should the CID be included in the additional data calculation, particularly for the case where it is only implicitly sent? Asked differently, are there attacks possible?

Your feedback would be appreciated to advance the discussion. I believe there is a chance to provide generic guidance for security protocol designers here.

Ciao
Hannes

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: Achim Kraus <[email-masked]>
Date: Fri, 24 Apr 2020 15:07:14 +0200

Hi Hannes,
Hi list,

as input for the discussion:

https://github.com/tlswg/dtls-conn-id/issues/25

A longer "comment-flow", the conclusion was, the CID is on the wire, so
it's in the MAC.
(ekr: "authenticating the whole header is just good practice.")

My arguments was, that the CID is always included in the MAC, either
explicit, or implicit (implicit, because the CID selects the "mac-keys"
or "cipher-keys" and gets included equal to the address:port before).

best regards
Achim

Am 24.04.20 um 13:04 schrieb Hannes Tschofenig:
> Hi all,
>
> the thread on the AEAD commutation in DTLS 1.3 and the construction of
> the additional data raised two interesting questions. I believe those
> would benefit from a formal analysis or at least a security investigation.
>
> Here are the questions:
>
>  1. Generic question: Should the construction of the additional data be
>     dependent on what is transmitted over the wire or should it be based
>     on a “pseudo header”? DTLS 1.2 uses a pseudo header and DTLS 1.3 the
>     data transmitted over the wire in the additional data calculation.
>  2. Specific question: Should the CID be included in the additional data
>     calculation, particularly for the case where it is only implicitly
>     sent? Asked differently, are there attacks possible?
>
> Your feedback would be appreciated to advance the discussion. I believe
> there is a chance to provide generic guidance for security protocol
> designers here.
>
> Ciao
>
> Hannes
>
> 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: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Apr 2020 14:48:07 +0000

Hi Achim,

My point is that we made decisions based on the best of our knowledge (and personal preferences) but I am wondering whether formal methods can tell us whether there is a preferred way.

Ciao
Hannes

-----Original Message-----
From: Achim Kraus <[email-masked]>
Sent: Friday, April 24, 2020 3:07 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [TLS] Choice of Additional Data Computation

Hi Hannes,
Hi list,

A longer "comment-flow", the conclusion was, the CID is on the wire, so it's in the MAC.
(ekr: "authenticating the whole header is just good practice.")

My arguments was, that the CID is always included in the MAC, either explicit, or implicit (implicit, because the CID selects the "mac-keys"
or "cipher-keys" and gets included equal to the address:port before).

best regards
Achim

Am 24.04.20 um 13:04 schrieb Hannes Tschofenig:
>     on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the
> Your feedback would be appreciated to advance the discussion. I
> believe there is a chance to provide generic guidance for security
> protocol designers here.
>
> Ciao
>
> Hannes
>
> 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: chris - <[email-masked]>
Date: Fri, 24 Apr 2020 11:56:54 -0400

Hi all,

>     data transmitted over the wire in the additional data calculation.

I'd like to point to some related work that could shed light on this
question. The decision for TLS 1.3 was to authenticate all data that is
written to the wire, as this allows for proving the record layer secure [1]
in a strong model for secure channels [2]. However, the formal models of
[1,2] assume reliable transport (i.e., TCP): failure to deliver packets in
order is deemed an attack. Therefore, the definitions would need to be
changed in order to account for the case of DTLS. (I'm not sure if this has
been studied.) My hunch is that the same design pattern (i.e.,
"authenticate everything on the wire") would be called for, but I've not
seen formal evidence either way.

>     sent? Asked differently, are there attacks possible?

Unfortunately I'm unfamiliar with the specific problem at hand, as I've not
been following DTLS' development. (I'm in the middle of writing my thesis.)
That said, I don't see a problem with having the AAD include *both* the
record heard  *and*  something else, like the CID. And it may very well
prevent an attack.

Chris P.

[1] https://eprint.iacr.org/2018/634.pdf
[2] https://eprint.iacr.org/2017/1191.pdf

---

From: Hanno Becker <[email-masked]>
Date: Fri, 24 Apr 2020 16:19:46 +0000

Hi Chris,

Just a note on the comparison with TLS 1.3.

> I'd like to point to some related work that could shed light on this question.
> The decision for TLS 1.3 was to authenticate all data that is written to the wire,

It doesn't seem straightforward to extrapolate from that case since the 'pseudo-header'
and on-the-wire header are the same here, as TLS 1.3 doesn't have any header
data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, various
fields can be dropped or shortened, such as the length, sequence number, CID.

Best,
Hanno
________________________________
From: TLS <[email-masked]> on behalf of chris - <[email-masked]>
Sent: Friday, April 24, 2020 4:56 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] Choice of Additional Data Computation

Hi all,

>     data transmitted over the wire in the additional data calculation.

I'd like to point to some related work that could shed light on this question. The decision for TLS 1.3 was to authenticate all data that is written to the wire, as this allows for proving the record layer secure [1] in a strong model for secure channels [2]. However, the formal models of [1,2] assume reliable transport (i.e., TCP): failure to deliver packets in order is deemed an attack. Therefore, the definitions would need to be changed in order to account for the case of DTLS. (I'm not sure if this has been studied.) My hunch is that the same design pattern (i.e., "authenticate everything on the wire") would be called for, but I've not seen formal evidence either way.

>     sent? Asked differently, are there attacks possible?

Unfortunately I'm unfamiliar with the specific problem at hand, as I've not been following DTLS' development. (I'm in the middle of writing my thesis.) That said, I don't see a problem with having the AAD include *both* the record heard  *and*  something else, like the CID. And it may very well prevent an attack.

Chris P.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 09:44:04 -0700

On Fri, Apr 24, 2020 at 9:20 AM Hanno Becker <[email-masked]> wrote:

> question.

I'm not sure if it's straightforward, but I would note that in TLS 1.3, we
did *implicitly* authenticate the length because AEAD provides that, but
nevertheless one of Chris's recommendations was to include it in the AAD.

-Ekr

> Best,
> Hanno
> ------------------------------
> *From:* TLS <[email-masked]> on behalf of chris - <
> [email-masked]>
> *Sent:* Friday, April 24, 2020 4:56 PM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [TLS] Choice of Additional Data Computation
>
> Hi all,
>
>
> Unfortunately I'm unfamiliar with the specific problem at hand, as I've
> not been following DTLS' development. (I'm in the middle of writing my
> thesis.) That said, I don't see a problem with having the AAD include
> *both* the record heard  *and*  something else, like the CID. And it may
> very well prevent an attack.
>
>
> Chris P.
>
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.

---

From: chris - <[email-masked]>
Date: Fri, 24 Apr 2020 13:57:03 -0400

> fields can be dropped or shortened, such as the length, sequence number,

It's certainly true that we can't extrapolate the security of DTLS from the
existing proof for TLS. In the first place, the threat model is different
because in DTLS we need to tolerate dropped/out-of-order packets.
Nevertheless, I think the general principle of "authenticate all the bits"
is the right way to go here, unless there's a compelling reason not to.

In the case of TLS 1.3, authenticating the entire header (including the
length, opaque type, and legacy record version) allowed us to effectively
ignore most of the header details in the security proof [1]: all we cared
about is that the header correctly encodes the length of the next
ciphertext to decrypt. We might be able to provide a similar argument for
DTLS 1.3. In particular, I'm betting that it doesn't matter what the
contents of the header are or how long it is, so long as (a) the entire
header is part of the AAD and (b) it correctly encodes the length of the
next ciphertext.

I might be missing something, however. In any case, new definitions are
needed (if they don't already exist) and so too a fresh proof.

Chris P.

---

From: Hanno Becker <[email-masked]>
Date: Fri, 24 Apr 2020 18:17:33 +0000

Hi Chris and Ekr,

> I'm not sure if it's straightforward, but I would note that in TLS 1.3, we did *implicitly* authenticate the length because AEAD provides that, but nevertheless one of Chris's recommendations was to include it in the AAD.

I don't know if this recommendation still holds for DTLS (though Chris' last reply sounds
like it), but DTLS 1.3 currently deviates from it: The length is explicitly authenticated only
for records using header formats which contain the length, while for the most compressed header
form omitting the length one relies on implicit length authentication via AEAD.

> In the case of TLS 1.3, authenticating the entire header (including the length, opaque type, and legacy record version) allowed us to effectively ignore most of the header details in the security proof [1]:

If the security analysis shall be agnostic of header details, then in the case of
DTLS 1.3 with its various header formats (https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4),
it sounds to me as if using a pseudo-header containing all header information for AAD would fit better (?).

Best,
Hanno

________________________________
From: chris - <[email-masked]>
Sent: Friday, April 24, 2020 6:57 PM
To: Eric Rescorla <[email-masked]>
Cc: Hanno Becker <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] Choice of Additional Data Computation

It's certainly true that we can't extrapolate the security of DTLS from the existing proof for TLS. In the first place, the threat model is different because in DTLS we need to tolerate dropped/out-of-order packets. Nevertheless, I think the general principle of "authenticate all the bits" is the right way to go here, unless there's a compelling reason not to.

In the case of TLS 1.3, authenticating the entire header (including the length, opaque type, and legacy record version) allowed us to effectively ignore most of the header details in the security proof [1]: all we cared about is that the header correctly encodes the length of the next ciphertext to decrypt. We might be able to provide a similar argument for DTLS 1.3. In particular, I'm betting that it doesn't matter what the contents of the header are or how long it is, so long as (a) the entire header is part of the AAD and (b) it correctly encodes the length of the next ciphertext.

I might be missing something, however. In any case, new definitions are needed (if they don't already exist) and so too a fresh proof.

Chris P.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 11:32:16 -0700

On Fri, Apr 24, 2020 at 11:17 AM Hanno Becker <[email-masked]> wrote:

> Hi Chris and Ekr,
>
> > I'm not sure if it's straightforward, but I would note that in TLS 1.3,
> we did *implicitly* authenticate the length because AEAD provides that, but

Yes, that's correct. But you can't swap header formats.

> ignore most of the header details in the security proof [1]:
>
> DTLS 1.3 with its various header formats (
> https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4),
> it sounds to me as if using a pseudo-header containing all header
> information for AAD would fit better (?).
>

I don't think that's at all obvious. Again, the problem with the
pseudo-header is you are authenticating some abstract information, *not*
what is actually on the wire, and that allows the attacker to manipulate
what's on the wire undetected. We have no analysis for the impact of that.

-Ekr

> *From:* chris - <[email-masked]>
> *Sent:* Friday, April 24, 2020 6:57 PM
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* Hanno Becker <[email-masked]>; Hannes Tschofenig <
> [email-masked]>; [email-masked] <[email-masked]>
> It's certainly true that we can't extrapolate the security of DTLS from
> the existing proof for TLS. In the first place, the threat model is
> different because in DTLS we need to tolerate dropped/out-of-order packets.

---

From: chris - <[email-masked]>
Date: Fri, 24 Apr 2020 14:51:33 -0400

> what's on the wire undetected. We have no analysis for the impact of that.

Yes, this is the way I see it. I think you can get by with implicitly
authenticating things, but when you start doing this, the details of how to
decode the data on the wire begin to really matter for the proof (and
potentially for an attacker). This can get complicated if, as you say, the
header's content is highly variable. So, I would recommend authenticating
what's on the wire. I don't think it would hurt to authenticate more than
this, e.g., other fields that the sender and receiver need to agree on.

Chris P.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 11:56:11 -0700

> this, e.g., other fields that the sender and receiver need to agree on.

FWIW, if the consensus of the group were to authenticate both the
"pseudoheader information" and the bits on the wire, I could potentially
live with that.

My rank ordering of options I consider potentially acceptable is:

1. Ban implciit CIDs.
2. Authenticate both the wire format and the abstract information.

I am strongly opposed to authenticating only the abstract information.

-Ekr

P.S. QUIC uses the same implicit length mechanism, so we should form a
common theory.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 24 Apr 2020 19:56:08 +0000

On 24/04/2020, 19:53, "chris -" <[email-masked]> wrote:
> [...] the details of how to decode the data on the wire begin to
> really matter for the proof (and potentially for an attacker).

I have zero experience with formal security proofs, so I need to trust
your assessment here, which looks like the crux of the argument against
authenticating the pseudo-header alone.

> I don't think it would hurt to authenticate more than this, e..g.,
> other fields that the sender and receiver need to agree on.

IIUC the other seemingly critical thing for the security proof of TLS,
which I think it's critically important we try hard not to diverge from, was
authenticating the length of the record:

> [...] all we cared about is that the header correctly encodes the
> length of the next ciphertext to decrypt.

The thing is with UDP it is trivial for an attacker to truncate a
datagram and therefore change the *implicit* length of the carried
record and go undetected if that is not included in the authenticated
data.  So it seems that - at a minimum - we should always authenticate
the length even when it is not put on the wire.

And if we need to do that, keeping the implicit CID looks like a
no-brainer to me.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 13:42:33 -0700

> And if we need to do that, keeping the implicit CID looks like a

I do want to be clear that AEAD functions implicitly authenticate the
length of the input. But I'd like to hear Chris weigh in on whether he
thinks we should have them explicitly in the AD (and whether that should be
true in QUIC too).

-Ekr

---

From: chris - <[email-masked]>
Date: Fri, 24 Apr 2020 17:29:29 -0400

>
> But I'd like to hear Chris weigh in on whether he thinks we should have
> them explicitly in the AD (and whether that should be true in QUIC too).
>

I would need to study the specs in order to provide an intelligent answer
here. Off the hip, it would seem to depend on how the boundaries between
record headers and ciphertexts are determined. Taking a quick look at
draft-37, Fig. 4: the "full" header includes three values that are excluded
from the "minimal" header, the length of the ciphertext being one of the
fields. Presumably, when using the "minimal" header, the length is a
parameter that the sender and receiver already agree on. If this is case,
then I don't see a need to add the length to the AD. If the attacker
manages to convince the receiver to use the wrong length parameter (maybe
this is negotiated during the handshake?), then as Ekr points out, AEAD
decryption would fail, thereby "implicitly authenticating the input length".

Chris P.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 14:34:37 -0700

On Fri, Apr 24, 2020 at 2:29 PM chris - <[email-masked]> wrote:

> parameter that the sender and receiver already agree on.
>

Yes. It's "the rest of the UDP datagram".

-Ekr

> If this is case, then I don't see a need to add the length to the AD. If
> the attacker manages to convince the receiver to use the wrong length
> parameter (maybe this is negotiated during the handshake?), then as Ekr
> points out, AEAD decryption would fail, thereby "implicitly authenticating
> the input length".
>
> Chris P.
>

---

From: Hanno Becker <[email-masked]>
Date: Fri, 24 Apr 2020 22:00:04 +0000

Hi,

Thanks for your input Chris, this is very helpful.

Yes, this is the way I see it. I think you can get by with implicitly authenticating things, but when you start doing this, the details of how to decode the data on the wire begin to really matter for the proof (and potentially for an attacker). This can get complicated if, as you say, the header's content is highly variable. So, I would recommend authenticating what's on the wire. I don't think it would hurt to authenticate more than this, e.g., other fields that the sender and receiver need to agree on.

So far I fail to understand, on an intuitive level, why it easier to analyze the protocol when the AAD can take multiple forms potentially truncating or omitting the underlying data, but then I don't know the details and you're the expert here. If you have time though to explain a bit more where the flaw in my thinking below is, that would be great, provided it's possible.

For example, another thing which I would expect to be more complicated to verify in full rigor is epoch authentication: If the epoch is reduced to its two low order bits in the DTLS 1.3 header and thus (at the moment) also in the AAD, arguing that decryption can only succeed for the correctly expanded epoch involves knowing that all epochs having different keys. That's of course true but this fact wouldn't be needed if the full numeric epoch was always explicitly authenticated in the AAD. This isn't a real issue in the end, but I would expect it to be a nuisance in a formal proof?
In terms of what you mentioned regarding decoding details, it seems that adding the underlying logical header to the AAD ensures more directly that decryption can only succeed if header decoding (that is, filling in implicit data or expanding truncated data) was done correctly, whereas it is less clear with the truncated or omitted data in AAD, as in the epoch example above. Is it possible to explain what the flaw is here intuitively?

Thanks again,
Hanno

---

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

On 24/04/2020, 22:35, "Eric Rescorla" <[email-masked]> wrote:
> > I would need to study the specs in order to provide an intelligent
> > answer here. Off the hip, it would seem to depend on how the
> > boundaries between record headers and ciphertexts are determined.
> > Taking a quick look at draft-37, Fig. 4: the "full" header includes
> > three values that are excluded from the "minimal" header, the length
> > of the ciphertext being one of the fields. Presumably, when using
> > the "minimal" header, the length is a parameter that the sender and
> > receiver already agree on.
>

I might be missing something but this doesn't look to me like the
definition of "agreed upon" by the TLS principals: an attacker can
modify what "the rest of the datagram" is at will, no?

---

From: chris - <[email-masked]>
Date: Sat, 25 Apr 2020 13:58:29 -0400

> So far I fail to understand, on an intuitive level, why it easier to
> analyze the protocol when the AAD can take multiple forms potentially
> truncating or omitting the underlying data, but then I don't know the
> details and you're the expert here. If you have time though to explain a
> bit more where the flaw in my thinking below is, that would be great,
> provided it's possible.
>

I don't know that there's a flaw in your thinking. At the moment, all that
I can speak to is how authenticating the header (or not) might impact
security of DTLS. We can't directly extrapolate from what we know about
TLS, because the security goal is not to the same. That said what I know
about TLS is the following: the contents of the record header doesn't
matter for security goal considered in [1], as long as (1) the header is
authenticated; and (2) it correctly encodes the length of the next
ciphertext. But since the security goal of DTLS is not the same, the
details of the spec that are (ir)relevant to security are likely to differ.

> For example, another thing which I would expect to be more complicated to
> verify in full rigor is epoch authentication: If the epoch is reduced to
> its two low order bits in the DTLS 1.3 header and thus (at the moment) also
> in the AAD, arguing that decryption can only succeed for the correctly
> expanded epoch involves knowing that all epochs having different keys.
> That's of course true but this fact wouldn't be needed if the full numeric
> epoch was always explicitly authenticated in the AAD. This isn't a real
> issue in the end, but I would expect it to be a nuisance in a formal proof?
>
In terms of what you mentioned regarding decoding details, it seems that
> adding the underlying logical header to the AAD ensures more directly that
> decryption can only succeed if header decoding (that is, filling in
> implicit data or expanding truncated data) was done correctly, whereas it
> is less clear with the truncated or omitted data in AAD, as in the epoch
> example above. Is it possible to explain what the flaw is here intuitively?
>

I'm afraid I would need to absorb spec and think about its intended
security properties in order to answer these specific questions. I'm sorry
if this answer is unhelpful; Ekr asked that I chime due to my prior work on
TLS. But I don't think there's a simple answer here, and unfortunately I
don't have the time to think it through at the moment.

For now, I'll just leave you with this. I'm a fan of the following design
principle: whenever there is a branch in your code that depends on a bit
read from the wire, that bit should be authenticated if possible. To your
example, if a decision you're about to make depends on you agreeing with
the peer on the current epoch, the principle says that the epoch had better
be authenticated. Whether it's necessary or appropriate to do so here (via
AEAD decryption) depends very much on the context, i.e., the protocol
details and the security goal.

Chris P.

---

From: Hanno Becker <[email-masked]>
Date: Sun, 26 Apr 2020 09:43:21 +0000

Hi,

Thanks Chris for your thoughts.

Yes, it seems that specific formal analysis is needed, since we're dealing with the new
situation that - in contrast to TLS 1.3 - shortened or omitted fields in the DTLS 1.3 headers
(e.g. epoch, length, CID) introduce a notion of implicit context to a record which wasn't
present before. This requires analysis of the desired properties of this implicit context
and their implications on the protocol design.

For example, such a property might informally be that a party able to decrypt a record
must have correctly reconstructed the full implicit context of the record, such as the full
epoch when it was shortened in the header, the CID when it was omitted, or the length
when it was omitted. This seems most directly achieved by cryptographically binding this
context to the record through AAD, while protecting only the explicit context makes reasoning
that the party has the correct context either less straightforward (see the epoch example) or
impossible (current CID issue allowing to decrypt a record in a context with different CID).
To me it therefore still appears preferable to use a pseudo-header as the AAD.

Hopefully some more people from the protocol verification community
will join in here and give their thoughts.

Best,
Hanno
________________________________
From: chris - <[email-masked]>
Sent: Saturday, April 25, 2020 6:58 PM
To: Hanno Becker <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] Choice of Additional Data Computation

I don't know that there's a flaw in your thinking. At the moment, all that I can speak to is how authenticating the header (or not) might impact security of DTLS. We can't directly extrapolate from what we know about TLS, because the security goal is not to the same. That said what I know about TLS is the following: the contents of the record header doesn't matter for security goal considered in [1], as long as (1) the header is authenticated; and (2) it correctly encodes the length of the next ciphertext. But since the security goal of DTLS is not the same, the details of the spec that are (ir)relevant to security are likely to differ.

I'm afraid I would need to absorb spec and think about its intended security properties in order to answer these specific questions. I'm sorry if this answer is unhelpful; Ekr asked that I chime due to my prior work on TLS. But I don't think there's a simple answer here, and unfortunately I don't have the time to think it through at the moment.

For now, I'll just leave you with this. I'm a fan of the following design principle: whenever there is a branch in your code that depends on a bit read from the wire, that bit should be authenticated if possible. To your example, if a decision you're about to make depends on you agreeing with the peer on the current epoch, the principle says that the epoch had better be authenticated. Whether it's necessary or appropriate to do so here (via AEAD decryption) depends very much on the context, i.e., the protocol details and the security goal.

Chris P.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Apr 2020 14:09:13 -0700

On Sun, Apr 26, 2020 at 2:43 AM Hanno Becker <[email-masked]> wrote:

> when it was omitted.

The epoch, the sequence number, and the length are all bound to the AEAD
computation:

- The epoch determines the key
- The sequence number determines the nonce [note that this is actually
implicit in TLS 1.3]
- The length determines the input to the AAD.

And I am proposing removing implicit CIDs.

-Ekr

 This seems most directly achieved by cryptographically binding this
> *Sent:* Saturday, April 25, 2020 6:58 PM
> *To:* Hanno Becker <[email-masked]>
> *Cc:* Eric Rescorla <[email-masked]>; Hannes Tschofenig <

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 27 Apr 2020 10:13:31 +1000

On Sat, Apr 25, 2020, at 01:56, chris - wrote:
> However, the formal 
> models of [1,2] assume reliable transport (i.e., TCP): failure to 
> deliver packets in order is deemed an attack. Therefore, the 
> definitions would need to be changed in order to account for the case 
> of DTLS. (I'm not sure if this has been studied.) My hunch is that the 
> same design pattern (i.e., "authenticate everything on the wire") would 
> be called for, but I've not seen formal evidence either way.

A few of the submissions to QUIPS addressed this question for QUIC (which has a similar construction to DTLS) and concluded that this was broadly OK.  What changes is the degree to which we rely on the strength of the AEAD for prevention of spoofing.

(I'm sorry, but I can't find the paper that was most directly applicable, perhaps Felix can help out.  https://eprint.iacr.org/2020/114.pdf does a pretty good job, though it is a broader treatment.)

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Apr 2020 07:06:59 +0000

Hi Ekr,

  *   And I am proposing removing implicit CIDs

That would be a bit unfortunate. When we put multiple DTLS records in a single UDP datagram then the CID in all but the first datagram is redundant*.

Ciao
Hannes

(*): Even if we optimize the CID away with cTLS the question about the security implications will surface again.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 28 Apr 2020 08:25:37 +1000

On Mon, Apr 27, 2020, at 17:06, Hannes Tschofenig wrote:
> (*): Even if we optimize the CID away with cTLS the question about the 
> security implications will surface again. 

I think that cTLS is the answer to the size issue.  But there, the rule tends to be that removing from the wire doesn't also remove from the canonical value that is processed by the stack, so we might be able to send without a CID, but re-insert the value before processing.  As the canonical form, DTLS always including the value seems fine to me.