Skip to main content

Connection Identifier for DTLS 1.2
draft-ietf-tls-dtls-connection-id-13

Yes

Erik Kline
(Benjamin Kaduk)

No Objection

Roman Danyliw
Zaheduzzaman Sarker
(Alvaro Retana)
(Martin Vigoureux)

Note: This ballot was opened for revision 11 and is now closed.

Erik Kline
Yes
Francesca Palombini
No Objection
Comment (2021-04-20 for -11) Sent
Thank you for the work on this document. I only have minor comments and nits below.

Francesca


1. -----

   sending messages to the client.  A zero-length CID value indicates
   that the client is prepared to send with a CID but does not wish the
   server to use one when sending.

...

   to use when sending messages towards it.  A zero-length value
   indicates that the server will send with the client's CID but does
   not wish the client to include a CID.

FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO.

2. -----

   the record format defined in {{dtls-ciphertext} with the new MAC

FP: nit - missing "}" in markdown.

3. -----

   The following MAC algorithm applies to block ciphers that use the
   with Encrypt-then-MAC processing described in [RFC7366].

FP: remove "with"

4. -----

Section 10.1

FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value.

5. -----

Section 10.2 

FP: Just checking - why is 53 "incompatible with this document"?

6. -----

   Value   Extension Name  TLS 1.3  DTLS Only  Recommended  Reference

FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
John Scudder
No Objection
Comment (2021-04-20 for -11) Sent
I found this document heavy sledding but once I was through it, it all came together, with the exception of my #3, below. The “heavy sledding” part I think would be largely fixed by addressing my #1, below.

1. Section 3:

This pseudocode is a little too pseudo for me:

     struct {
         opaque cid<0..2^8-1>;
     } ConnectionId;

What does the content of the angle brackets mean? At first I took it to mean “this can take on a value from 0 to 255” [*] but parts of the spec that go on about variable lengths made me think that couldn’t be right. Eventually, by paging through RFC 5246, I found some explanations of what this stuff is supposed to mean; in §4.3 of that RFC I found out that 

   Variable-length vectors are defined by specifying a subrange of legal
   lengths, inclusively, using the notation <floor..ceiling>.  When
   these are encoded, the actual length precedes the vector's contents
   in the byte stream.  The length will be in the form of a number
   consuming as many bytes as required to hold the vector's specified
   maximum (ceiling) length.

I assume this is what’s going on in DTLS as well. This cleared up my main source of confusion, which was regarding just how you were encoding these variable-length CIDs anyway. (And oh by the way, that definition doesn’t say what the units of length are. Bytes seems implied but isn’t explicit.)

While I don’t expect you to supply these definitions again, it would be courteous to your readers to have a sentence or two explaining that pseudo-code conventions are found in RFC 5246, special extra credit for section references as well. And yes, I did notice "This document assumes familiarity with DTLS 1.2 [RFC6347].” That’s well and good, but I don’t think “familiarity” is the same as “we have adopted the same notational conventions”. 

[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew obfuscation!


2. Section 3:

   If DTLS peers have negotiated the use of a non-zero-length CID for a
   given direction, then once encryption is enabled they MUST send with
   the record format defined in {{dtls-ciphertext} with the new MAC
   computation defined in Section 5 and the content type tls12_cid.
   Plaintext payloads never use the new record type and the CID content
   type.

What’s “{{dtls-ciphertext}”? I’m guessing just a botched xref?  

Also, the first sentence seems to have no object. (What MUST they send?)


3. Section 6:

   *  There is a strategy for ensuring that the new peer address is able
      to receive and process DTLS records.  No such strategy is defined
      in this specification.

This is a little mind-boggling to me. I understand this to mean I can’t send the new address a DTLS record unless I’ve already ensured it can receive and process that record, right? This seems almost like a classic Catch-22. I feel like I must be missing something.
Murray Kucherawy
No Objection
Comment (2021-04-22 for -11) Sent
I concur with my colleagues that this was easy to understand.  Nice work.

I do get a little nervous these days at shepherd writeups that are over a year old.
Roman Danyliw
No Objection
Warren Kumari
No Objection
Comment (2021-04-20 for -11) Not sent
I opened this document with much trepidation -- I was expecting it to be horribly complex to read, and requiring much understanding of DTLS... but I was pleasantly surprised by just how readable / understandable it was.

I did find "Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for an endpoint to use a globally constant length for such connection  identifiers. " to be confusing. I was trying to figure out what *the* globally constant length is; global implied to me that everyone would use it. Could this be reworded to something like "for an endpoint to use a constant length for all such connection identifiers." or similar?
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2021-04-19 for -11) Sent
Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
As an important part of this document is the padding, should it be mentioned also in the abstract ?

-- Section 3 --
While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID."

-- Section 6 --
I am puzzled by the text:
     "There is a strategy for ensuring that the new peer address is able
      to receive and process DTLS records.  No such strategy is defined
      in this specification."
Does this mean that there is no way to update the peer IP address ?

== NITS ==

-- Section 1 --
Please expand CID on first use outside of the abstract.

-- Section 4 --
Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description.
Benjamin Kaduk Former IESG member
Yes
Yes (for -11) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (2021-04-22 for -11) Sent
All comments below are about potential very minor issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions. 

Section 3, paragraph 10, nit:
>    the record format defined in {{dtls-ciphertext} with the new MAC

Broken kramdown reference?

Section 1, paragraph 4, nit:
-    This document defines an extension to DTLS 1.2 to add a CID to the
+    This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to the
+                                                             ++++++++++  ++++++

Section 3, paragraph 7, nit:
-    for example by having the length in question be a compile-time
+    for example, by having the length in question be a compile-time
+               +

Section 3, paragraph 7, nit:
-    different length to other parties.  Implementations that want to use
-    variable-length CIDs are responsible for constructing the CID in such
+    different lengths to other parties.  Implementations that want to use
+                    +
+    variable-length CIDs are responsible for constructing the CIDs in such
+                                                                 +

Section 3, paragraph 12, nit:
-    datagram with the RFC 6347-defined record format the MAC calculation
+    datagram with the RFC 6347-defined record format, the MAC calculation
+                                                    +

Section 4, paragraph 6, nit:
-    *  The true content type is inside the encryption envelope, as
-           - -
+    *  The real content type is inside the encryption envelope, as
+             ++

Section 6, paragraph 2, nit:
-    datagram unless the following three conditions are met:
+    datagram, unless all of the following three conditions are met:
+            +       +++++++

Section 10, paragraph 2, nit:
-    This document requests three actions by IANA.
-                                         ^^
+    This document requests three actions from IANA.
+                                         ^^^^

Section 4, paragraph 17, nit:
> cord. outer_type The outer content type of a DTLSCiphertext record carrying a 
>                                    ^^^^^^^^^
If 'type' is a classification term, 'a' is not necessary. Use "type of". (The
phrases 'kind of' and 'sort of' are informal if they mean 'to some extent'.)

Section 4, paragraph 19, nit:
> the CID value it will receive and use to identify the connection, so an implemen
>                                   ^^^^^^
Make sure that 'use to' is correct. For habitual actions in the past or to mean
'accustomed to', use "used to".

Section 5, paragraph 6, nit:
> Plaintext The length (in bytes) of the serialised DTLSInnerPlaintext (two-byte inte
>                                        ^^^^^^^^^^
Do not mix variants of the same word ('serialise' and 'serialize') within a
single text.

Section 6, paragraph 2, nit:
>  that has a source address different than the one currently associated with the D
>                                      ^^^^
Did you mean 'different "from"? 'Different than' is often considered colloquial
style.

Section 6, paragraph 2, nit:
> ied in the received datagram, unless all of the following three conditions are met: 
>                                      ^^^^^^^^^^
Consider using "all the".

"Appendix A.", paragraph 1, nit:
>  History RFC EDITOR: PLEASE REMOVE THE THIS SECTION draft-ietf-tls-dtls-connect
>                                    ^^^^^^^^
Maybe you need to remove the second determiner so that only "THE" or "THIS" is
left.

"Appendix A.", paragraph 29, nit:
> 2 * Move to internal content types a la DTLS 1.3. draft-ietf-tls-dtls-conne
>                                    ^^^^
'a la' is an imported foreign expression, which originally has a diacritic.
Consider using "à la"

"Appendix B.", paragraph 1, nit:
> formation RFC EDITOR: PLEASE REMOVE THE THIS SECTION The discussion list for the
>                                     ^^^^^^^^
Maybe you need to remove the second determiner so that only "THE" or "THIS" is
left.

"Appendix C.", paragraph 1, nit:
>  Many people have contributed to this specification and we would like to thank the following
>                                       ^^^^^^^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

These reference issues exist in the document:
 * No reference entries found for: 
     [ChangeCipherSpec], [length], [length_of_padding],
     [DTLSCiphertext.length],
     [draft-rescorla-tls-dtls-connection-id-00],
     [cid_length], [DTLSPlaintext.length]
 * Uncited references: [RFC5246]
 * Obsolete reference to RFC5246, obsoleted by RFC8446

These URLs in the document did not return content:
 * https://www1.ietf.org/mailman/listinfo/tls
 * http://www.ietf.org/internet-drafts/draft-tschofenig-tls-dtls-rrc-01.txt
 * http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-40.txt
Martin Duke Former IESG member
No Objection
No Objection (2021-04-20 for -11) Sent
Thanks for this document.

Section 9.3.3 of quic-transport, which deals with basically the same security model, also requires the receiving endpoint to probe the original address, not just the new one, to address a somewhat more difficult attack. It would be good to at least RECOMMEND this behavior for DTLS applications, and/or (repeat/informatively reference) the logic there.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2021-04-19 for -11) Sent
Hi,

I'm no DTLS expert, but I found the concepts/explanation in this document easy to follow.

I was slightly confused by the requirement to encode the length in variable length CIDs, and had to read the relevant text a second time.   As a suggestion, it might help if these two sentences were reworded the other way round:

OLD:
Implementations that want to use
   variable-length CIDs are responsible for constructing the CID in such
   a way that its length can be determined on reception.  Note that
   there is no CID length information included in the record itself.

NEW:
Since the CID length information is not included in the record itself, implementations that want to use ... <as before>.

One minor question.  In the contributors, I noted that Jana is listed as being associated with Google, but it might be worth checking if that is still accurate.

Regards.
Rob