Re: [TLS] DTLS 1.3 AEAD additional data

[Hanno Becker <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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

Would like to hear what others in the WG think.

-Ekr


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


On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <[e-mail]<mailto:[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]<mailto:[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.