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

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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?

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

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

[Ballot 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

[Ballot comment]
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 ... .

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

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-dtls-connection-id-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a new column - "DTLS Only?" - will be added to the registry and [ RFC-to-be ] will be added as an additional reference for the registry.

IANA Question --> What are the entries for DTLS Only? for the existing registrations in the current registry?

Second, also in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the temporary registration for value 53 connection_id will be updated as follows:

Value: 53
Extension Name: connection_id
TLS 1.3: CH, SH
DTLS Only: Y
Recommended: N
Reference: [ RFC-to-be ]

Since the TLS 1.3 column has been updated, we're asking the TLS ExtensionType Value experts to review and approve. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the TLS ContentType registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

the temporary registration for value 25 (tls12_cid) will be made permanent and the reference will be changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-03-28):

From: The IESG
To: IETF-Announce
CC: Joseph Salowey , draft-ietf-tls-dtls-connection-id@ietf.org, joe@salowey.net, kaduk@mit.edu, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Connection Identifiers for DTLS 1.2) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Connection Identifiers for DTLS 1.2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the Connection ID (CID) construct for the
  Datagram Transport Layer Security (DTLS) protocol version 1.2.

  A CID is an identifier carried in the record layer header that gives
  the recipient additional information for selecting the appropriate
  security association.  In "classical" DTLS, selecting a security
  association of an incoming DTLS record is accomplished with the help
  of the 5-tuple.  If the source IP address and/or source port changes
  during the lifetime of an ongoing DTLS session then the receiver will
  be unable to locate the correct security context.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The proposed Status of the document is Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies the Connection ID (CID) construct for the
  Datagram Transport Layer Security (DTLS) protocol version 1.2.

  A CID is an identifier carried in the record layer header that gives
  the recipient additional information for selecting the appropriate
  security association.  In "classical" DTLS, selecting a security
  association of an incoming DTLS record is accomplished with the help
  of the 5-tuple.  If the source IP address and/or source port changes
  during the lifetime of an ongoing DTLS session then the receiver will
  be unable to locate the correct security context.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document is of interest to a subset of the working group
participants.  The participants are active and there is general
working group consensus behind the document. 

Document Quality

The document has been reviewed by people implementing
the protocol.  There are multiple implementations of this
extension.

Personnel

The Document Shepherd is Joseph Salowey and the responsible AD is Ben Kaduk

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed the document and believes it is ready for publication. 
The reference to the obsoleted TLS version is intentional. 
The document needs to have a reference to RFC 6347 added to the abstract as it
only mentions the document by name.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Specific Concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors have confirmed conformance with BCP 78 and BCP 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No declared IPR

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been worked on by a subset of the TLS community.
The document has had review from participants outside this
subset and there is general consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

NA

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No Nits

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document updates RFC 6347 (DTLS 1.2).  The abstract mentions DTLS 1.2
but does not include the RFC number reference.  This can be easily fixed
later in the process

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations registers an entry for the extension and content
type associated with this document

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The proposed Status of the document is Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies the Connection ID (CID) construct for the
  Datagram Transport Layer Security (DTLS) protocol version 1.2.

  A CID is an identifier carried in the record layer header that gives
  the recipient additional information for selecting the appropriate
  security association.  In "classical" DTLS, selecting a security
  association of an incoming DTLS record is accomplished with the help
  of the 5-tuple.  If the source IP address and/or source port changes
  during the lifetime of an ongoing DTLS session then the receiver will
  be unable to locate the correct security context.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document is of interest to a subset of the working group
participants.  The participants are active and there is general
working group consensus behind the document. 

Document Quality

The document has been reviewed by people implementing
the protocol.  There are multiple implementations of this
extension.

Personnel

The Document Shepherd is Joseph Salowey and the responsible AD is Ben Kaduk

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed the document and believes it is ready for publication. 
The reference to the obsoleted TLS version is intentional. 
The document needs to have a reference to RFC 6347 added to the abstract as it
only mentions the document by name.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Specific Concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors have confirmed conformance with BCP 78 and BCP 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No declared IPR

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been worked on by a subset of the TLS community.
The document has had review from participants outside this
subset and there is general consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

NA

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No Nits

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document updates RFC 6347 (DTLS 1.2).  The abstract mentions DTLS 1.2
but does not include the RFC number reference.  This can be easily fixed
later in the process

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations registers an entry for the extension and content
type associated with this document

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The proposed Status of the document is Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies the Connection ID (CID) construct for the
  Datagram Transport Layer Security (DTLS) protocol version 1.2.

  A CID is an identifier carried in the record layer header that gives
  the recipient additional information for selecting the appropriate
  security association.  In "classical" DTLS, selecting a security
  association of an incoming DTLS record is accomplished with the help
  of the 5-tuple.  If the source IP address and/or source port changes
  during the lifetime of an ongoing DTLS session then the receiver will
  be unable to locate the correct security context.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document is of interest to a subset of the working group
participants.  The participants are active and there is general
working group consensus behind the document. 

Document Quality

The document has been reviewed by people implementing
the protocol

Personnel

The Document Shepherd is Joseph Salowey and the responsible AD is Ben Kaduk

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Specific Concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Check in progress

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No declared IPR

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been worked on by a subset of the TLS community,
but the document has had review from participants outside this
subset and there is general consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

NA

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No Nits

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

TBD

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

In Porgress

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA