tlswg / dtls-conn-id Goto Github PK

https://mailarchive.ietf.org/arch/msg/tls/Vg7QymL8fu-pAHw9Bs4CD46KC_U/

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

https://mailarchive.ietf.org/arch/msg/tls/0hyoFBsJ_21mv2hUEPPQhmGOMes/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

Considering, that sending records with "spoofed, valid CIDs" (e.g. read by some component on the path), will be not too hard, that may cause some smaller DoS scenarios. Though the record's MAC needs to be calculated to sort such records out, exactly that calculation may already consume more CPU resources, than expected. That doesn't really introduce a new thread, though ip-address spoofing was considered for DTLS before, but in difference to that ip-address spoofing, it maybe considered to be easier to spoof such valid CIDs.

To mitigate such DoS scenario, a CIDAC could be useful, if it could be calculated essentially faster than the record's MAC. To only prevent from DoS, the focus is more on efficiency than security (that will still be provided by the record's MAC). So my idea would be to add e.g. a 3 bytes CIDAC to the end of the CID in the TLS_CID record. Even with a weak CIDAC function may provide a 1/1000 ratio against "CID spoofing" (means: only 1 of 1000 spoofed CID records may pass that filter, but will then be blocked by the record's MAC). One idea for calculating such CIDAC would be to use SHA-256, feed in the MAC keys and then add the first bytes up to and including the record length, but excluding the 3 bytes CIDAC. Using the MAC keys may also enable implementations to apply that filter even earlier in the processing, e.g. firewalls or load-balancers (sometime in the future :-) ).

Though I'm still not common to DTLS 1.3, this idea may be not new. Even then, I would appreciate feedback.

https://mailarchive.ietf.org/arch/msg/tls/urqyTwgp7sP7w40bFUhpCVPma-Y/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

In order to prevent this, implementations SHOULD
attempt to use fresh connection IDs whenever they change local
addresses or ports (though this is not always possible to detect).

There is no way in which an endpoint can do this in this version of the specification, absent creating a new connection.

Block Ciphers: tls12_cid
Block Ciphers with Encrypt-then-MAC: DTLSCipherText.type
AEAD Ciphers: DTLSPlaintext.type

May be the terms could be harmonized?

In my opinion, it's the actual cid on the record header, not the negotiated cid, even if both are intended to be the same. Therefore it is DTLSCiphertext.cid.

Or has this changed? Is the MAC now extended by the negotiated CID?

This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID".

Probably more seriously, that first mention is actually to cite a struct:

The extension_data field of this extension, when included in the ClientHello, MUST contain the CID structure, which carries the CID [...]

The structure is called ConnectionId.

We currently only describe CID processing with AEAD ciphersuites, which seems to imply that the CID extension effectively influences ciphersuite negotiation.

The draft should explain how the two - ciphersuite negotiation and CID ext - interact.

Some things you might want to consider in AUTH48 (I see that EKR has not approved yet).

• "The received datagram is "newer""
  This requirement seems to be missing from the DTLS 1.3 draft.

• "There is a strategy for ensuring that the new peer address"
  This requirement seems much weaker that the "DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some reachability test" in DTLS 1.3. A "strategy" seems like a plan for doing something later. The DTLS 1.3 text seems preferable.

Feels spontaneously like DTLS 1.2 and 1.3 should have very similar requirements/guidance on "peer address update".

• Would be good to warn implementations that clients must not update the permanent server address based on the “Peer Address Update” mechanism. Using IP addresses instead of DNS names is not uncommon in e.g., IoT, DNS over DTLS (RFC 8094), and 3GPP DTLS interfaces.

• Would be good with a sentence or two on the problems with changing the IP address of a gateway multiplexing a lot of DTLS connection with Connection ID. All the client and servers would have to send at least one record before the old IP address can be deactivated. Might take some time in a IoT deployment.

Russ Housley's secdir review: https://mailarchive.ietf.org/arch/msg/tls/dI-hAovkWRPNUg8JRrBS4de1uUw/

Section 4: For increased clarity, I suggest:
OLD:
   real_type  The content type describing the payload.
NEW:
   real_type  The content type describing the cleartext payload.

If a cid is negotiated for a connection-endpoint, is it then intended to use that in all records for that connection-endpoint (at least all first records of a datagram)?

The discussion in the IETF TLS mailing list contains many examples with variable length CIDs, where the encoding is assumed to be ambiguous.

In my opinion, the encoding MUST be deterministic/unique.

Any different opinions?

Martin wrote:
https://mailarchive.ietf.org/arch/msg/tls/yG4msH0W6dlR-92FjwaACyvkT6Y

I would strike ", if these privacy properties are important in a given deployment" from the acknowledgments section (which is an odd place for the accompanying statement.

I would add an explicit note about the lack of CID update making this unsuitable for mobility scenarios. That's a common use case for this sort of mechanism, but this design lacks any defense against linkability.

It probably makes sense to be a little more consistent.

I miss the hint for the size of length_of_DTLSInnerPlaintext. I would assume it's a 2 bytes value. Is that right? Is this information already in the document and have overseen it?

length_of_DTLSInnerPlaintext

length of (IV + DTLSCiphertext.enc_content)

Both introduce a special "length" and use different approaches to do so. One with extra definition, one with a included definition. Is this intended?

Tom Petch's review: https://mailarchive.ietf.org/arch/msg/tls/Opmv1JCmY10uBKP1SrzfUpxhzCY/

s.4
/always recieve CIDs/always receive CIDs/


s.5.1
"the with Encrypt-then-MAC processing described in [RFC7366]."
I do not understand why 'with' is needed

s.5.2
ditto

s.8
/this aspects SHOULD refuse/these aspects SHOULD refuse/

Security and Privacy Considerations

The part

When a record with CID is received that has the source address of the enclosing
UDP datagram different from the one previously associated with that CID, the
receiver MUST NOT update its view of the peer’s address with the source
specified in the UDP packet before cryptographically validating the enclosed
record(s). This is to ensure that a man-on-the-side attacker that sends a
packet with a different source address on an existing CID session does not
successfully manage to reroute any return traffic.

of PR #65 didn't made to the draft, or did I miss it?

In the meantime, I would even go further:
Applying MAC and Anti-Replay may validates the record cryptographically, and so the receive windows may be updated and the application data may be forwarded. But, if the epoch/sequence_number is not newer than the newest successfully validate epoch/sequence_number before, the address update event itself may be wrong! Assuming, that a address-change is located somewhere on the message's route, it seems to be not possible to distinguish, if the message was delayed after the "address change" (and so that address is deprecated) or before that (and so the address would be the new one). If that could not be decided, I would go for updating the address only for newer records.
Using that approach, updating the address only for newer records (based on epoch/sequence_number) with validated MAC, would also mitigate the first two attacks of issue #64, though retransmitting an record with changed address will not update the address, because these records are NOT newer.

struct {
         opaque compressed[TLSCompressed.length];
         ContentType type;
         uint8 zeros[length_of_padding];
      } DTLSWrappedCompressed;

As far as I understand to notation above, opaque compressed[TLSCompressed.length] means just some bytes without an explicit encoded length (equivalent to opaque cid[cid_length]). So I'm not sure, how the TLSCompressed.lengthcould be determined. Could your provide me hint?
Or is there a other way, to find the position of the inner type byte?

https://mailarchive.ietf.org/arch/msg/tls/ssfL3x2jgoHWOx2RtK0033_V4K4/

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

Imagine the following:

• server S has an active session with client A using CID=1
• S crashes and restarts
• a new session using CID=1 is successfully established between S and client B
• A sends a record with CID=1
• MAC verification fails for the record

If at this point S decides not to follow the SHOULD silently discard recommendation in RFC 6347 and instead replIes to B (since A's address has not been validated) with a fatal MAC failure alert, a perfectly valid session would be killed.

https://mailarchive.ietf.org/arch/msg/tls/x-UCKxKC0Wk9HfZJh1-6Sud5oT0/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

Tom Petch's review: https://mailarchive.ietf.org/arch/msg/tls/Opmv1JCmY10uBKP1SrzfUpxhzCY/

s.3
I found this unclear until I had understood it all (or perhaps I do not
understand it)

"...or again, alternately, to use a zero-length CID)."
This suggests that a zero length CID is valid in Application Data which
later text seems to contradict; otherwise I cannot see what this is saying.

"  If DTLS peers have negotiated the use of a CIDs using the ClientHello
and the ServerHello messages "
arguably sending a zero CID and receiving a zero CID is a successful
Hello negotiation perhaps
" If DTLS peers have negotiated the use of a non-zero CID in at least
one direction, using the ClientHello and the ServerHello messages"

"The DTLS peers determine whether incoming and outgoing messages need.."
seems not to cater for unidirectional CIDs; perhaps
"The DTLS peers determine whether incoming or outgoing, or both,
messages need.. "

https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#record-layer-extensions

Note that for both record formats, it is not possible to parse the records without knowing how long the Connection ID is.

FMPOV, searching for the "length field" assuming that it's that uint16 pointing to the end of the UDP datagram, should result in many cases in the right length for the connection id. Moving the connection id after the "length field", will hide it from that search, but with the AEAD explicit nonce copied from the header, it will also be easy to find there.
Therefore, if it's intended to hide the connection id length in tls12_cid records, it must be after the "length field", and the explicit nonce could not longer be copied from the header to the fragment (saving 8 bytes).
It's no issue, if there is no intention to hide the connection id length. But then the misguided note above should be removed.

https://mailarchive.ietf.org/arch/msg/tls/R4Sh7CkbadK9bLCHzmfyGHKthqg/

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

Update from Éric re: Section 6

Re-reading the end of the section 6 gives indeed some insights on the
overall process, which I failed to understand at first reading. May I
suggest to complement the last bullet as "defined in this specification
but relies on the application using DTLS" ?

We currently have an early allocation of the TLS extensiontype codepoint 53 that was allocated on 2019-07-02.
An implementation of the draft at that time will no longer interoperate with the current specification due to changes in how the MAC inputs and AAD are laid out.

If we want to allocate a new extensiontype value for the new semantics, we should tell IANA that there is an existing early allocation and, e.g., that it should be left to expire (and what version of the draft to use as a reference until it does), with a new codepoint to be allocated in its stead.

We also have the option to direct IANA that "once this document is approved for publication, the early allocation will be deprecated and the following assignment will be made".

https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#examples

The example shows in flight 5

Certificate -------->
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished
(cid=100)

Does this imply that the flight 5 is send with cid = 100 or only the Finished?

I would prefer to be able to send also the other handshake messages of the flight with a cid, that would make it harder to disturb handshakes by spoofed handshake messages.

According https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#record-payload-protection all records seems to use a compressed : The value of DTLSCompressed.fragment. Does this include the CompressionMethod.null?

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?

Tom Petch's review: https://mailarchive.ietf.org/arch/msg/tls/Opmv1JCmY10uBKP1SrzfUpxhzCY/

s.2 lacks the boiler plate of RFC8174

Tom Petch's review: https://mailarchive.ietf.org/arch/msg/tls/Opmv1JCmY10uBKP1SrzfUpxhzCY/

s.10
I would find this clearer as three sections for the three IANA actions
10.1 new column for ExtensionType
10.2 new value for ExtensionType
10.3 new value for ContentType

"   IANA is requested to allocate an entry to the existing TLS
    "ExtensionType Values" registry, defined in [RFC5246],.."
well no; whatever you think of RFC8447 the name has changed
"   IANA is requested to allocate an entry to the existing "TLS
    ExtensionType Values" registry, defined in [RFC5246],.."
or, if you are picky (which I am not),
    IANA is requested to allocate an entry to the existing "TLS
    "ExtensionType Values" registry, defined in [RFC5246], and
    renamed by RFC8447

An extra column is added but I cannot see what value should be placed in
that column for existing entries.

"The tls12_cid ContentType is only applicable to DTLS 1.2."
Good information but I struggle to see what IANA will do with it; I see
nowhere for it to go.

https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#record-payload-protection-mac

    Block Ciphers with Encrypt-then-MAC processing:

    MAC(MAC_write_key, seq_num +
        DTLSCipherText.type +
        DTLSCipherText.version +
        DTLSPlaintext.version +
        cid +                   // New input
        cid_length +            // New input
        length of (IV + DTLSCiphertext.enc_content) +
        IV +
        DTLSCiphertext.enc_content);

contains two versions, DTLSCipherText.version and DTLSPlaintext.version.

Is this intended?

Alice has an active DTLS session + CID with Bob.

• Eve (man-on-the-side) sends junk packet with the CID currently in use between Alice and Bob and a spoofed source address of Victor
  • If Bob updates the peer address before the record is validated, he creates DoS/DDoS surface.
• Eve (man-on-the-side) replays previous packet from Alice and changes source address to that of Victor
  • If Bob has anti-replay disabled — even if he validates the records in the packet — he creates DoS/DDoS surface.
• Eve (man-in-the-middle) modifies packet from Alice to have the source address of Victor
  • Expanded DoS/DDoS surface is unavoidable.

While the first two can be addressed, I don't know how to stop (or even mitigate the third).

We should add text to the SecCons along the following lines:

[...]
When using CID, anti-replay MUST be enabled.
When a record with CID is received, the receiver MUST NOT update
its view of the peer address with the source specified in the UDP packet
before cryptographically validating the enclosed record(s).  Failing to do
so, creates a (D)DoS opportunity for a man-on-the-side attacker.
Use of CID creates the opportunity for an active man-in-the-middle to
trigger backscatter traffic for each CID-bearing packet it can modify.
[hic sunt leones]

Is there a implementation available to test interoperability?

I currently plan to introduce in a open source project (californium/scandium, https://github.com/eclipse/californium) and it would make it much easier, if such a implementation is available.

According the comment #25 (comment) I would assume, that this draft will be involved in future extensions.

If that assumption "future extensions" is true, the definition of ExtensionType should be extended from a "simple plain cid" to a "list of typed cids", where currently only the "plain" type is defined and used. That would allow future extensions for other cid types (e.g. types, which are less traceable).

If such future extensions should be supported, I have doubts about the current position of the cid, see my issue #27 . I would prefer to move the cid behind the length to protect it from being "discovered" too easy.

(I'm also OK, if this draft should be "finalized" and future extensions are not long considered for DTLS 1.2 . )

A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same).

This implies that an empty CID and an absent CID are identical. But they don't have to be. If both endpoints negotiate a zero- length CID, then this extension could be used to enable record padding.

The doc is not clear on this point. If a peer sends an empty connection_id extension, what are you supposed to do:

1. MUST send records in the old format.
2. MUST send tls12_cid records (which could be padded).
3. MAY send either.

It seems like option 2 or 3 give us a nice new feature - the ability to pad records - though 2 forces an additional overhead of 1 byte. Option 3 is somewhat less deterministic though (it doesn't seem like it would be harder to implement though).

An on-path adversary can create reflection attacks against third
parties because a DTLS peer has no means to distinguish a genuine
address update event (for example, due to a NAT rebinding) from one
that is malicious.  This attack is of concern when there is a large

This is why we have the "[t]here is a strategy for ensuring that the new
peer address is able to receive and process DTLS records" requirement,
right? We should probably mention that (and that it's not perfect,
since you have to send some records to the not-yet-verified peer address
as part of the verification process).

Given that the details of how this works in DTLS 1.3 are now in the DTLS 1.3 spec, it's probably best to have a title of something like "Connection Identifiers for DTLS 1.2".

If you subscribe to the theory that DTLS has to mux with the realtime protocols, this takes a good slice of the remaining codepoints space. Though TLS has between 20 and 63, DTLS 1.3 takes 32-63 and the registration of 4 more would leave just 3: 29, 30, and 31.

I submit that we might be better considering the TLS 1.3 record construction with a single codepoint. That would get us content type encryption and arbitrary padding as a secondary benefit. All for the modest cost of one octet.

A couple of tweaks are needed for the IANA Considerations Section:

• Based on input from the IANA TLS DEs, it seems like we need a column added to the TLS ExtensionType Values registry to indicate that an extension is DTLS-only.
• The column values for TLS 1.3 and Recommended are missing. Suggest blank for TLS 1.3 and N for Recommended.
• Add a note to say that connection_id is DTLS1.2 only.
• Add instructions for IANA to assign "Y" to DTLS-okay column for tls12_cid content type.

In Figure 2, parentheses are used to signify both extensions (connection_id=100) and the addition to the record header (cid=100). I suggest using a different notation here.

https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#record-payload-protection

According RFC5246, the record layer protection is split into 3 sections

• NULL and stream (stream is not used for DTLS)
• CBC
• AEAD

in this draft, only the NULL is referenced
https://tools.ietf.org/html/rfc5246#section-6.2.3.1

If the CID value should be included in that MAC, I would expect, that this draft specifies how to do this for all three variants. By the way, I'm not sure, why the CID should be explicitly included. The CID "points" to the "keys" used to calculate the MAC, with a wrong CID, the wrong "key" will be used and that should cause a MAC violation anyway.

https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#iana-considerations

Still contains the content types removed in PR #13.

• alert_with_cid(25)
• handshake_with_cid(26)
• application_data_with_cid(27)
• heartbeat_with_cid(28)

I guess, it should be updated towards PR #13?

• tls12_cid(25)

         MAC(MAC_write_key, DTLSCompressed.epoch +
                               DTLSCompressed.sequence_number +
                               DTLSCompressed.type +
                               DTLSCompressed.version +
                               connection_id + // New field
                               cid_length +        // New input
                               cid +               // New input
                               DTLSCompressed.length +
                               DTLSCompressed.fragment);

I assume that cid and connection_id are the same thing.

During the discussion of the last weeks, my impression of the scope of this draft has changed.

At the begin it was clearly the solution for issues caused by a NAT.

With the questions from others about the usage of a empty CID in the MAC, I started to wonder, why this should be used. In the meantime in think, using the new record type (even with an empty CID) would enable peers to obfuscate the DTLS payload length. That feature may be even used without a real CID (therefore using a empty CID). I'm not sure, if this is really planned. I asked for it, but unfortunately, didn't receive an answer. If that usage is planned, I think it should be addressed explicitly.
See:
Issue #22
#35 (comment)

And working on the implementation, I got also the idea, to use this extension to improve the protection of the handshake itself (see #26). Currently the protection seems to be mainly the "randomness of the ip-address:port". But this randomness is not really defined and so using a random CID to lock the handshake may help. The interesting point of this usage would be, that it get's more important, when the address doesn't change (less randomness), so it targets the opposite environment as the original idea (frequently changing (by NAT) to static reachable). In the end this may end up in a "large CID used in the handshake" and no need to use the CID after the handshake.

With these other "use-cases", I'm not sure, if the "strict" definitions in #28 should be implemented or if the definitions should be "relaxed".
The worst case would be, that the "strict" is mostly implemented, but the users also want the other scenarios independent for the "original idea".

If this feature is negotiated on, then the MAC calculation changes, even if no connection ID is sent, because of cid_length. This needs to be clearly sign-posted.

Section 8

With multi-homing, a passive attacker is able to correlate the
communication interaction over the two paths and the sequence number
makes it possible to correlate packets across CID changes. The lack

DTLS 1.2 CIDs don't have CID changes (other than by rehandshaking, which
resets the sequence number space); the last clause seems stale from DTLS
1.3?