Draft: draft-ietf-tls-dtls-connection-id

Commentary: Clarify that successfully negotiating two zero - len CIDs is the same as failing the negotiation in terms of what happens on the wire afterwards . 
 For me , this PR makes it clearer and better understandable . 
    review : 
 My feeling : remove " ( or again , alternately , to use a zero - length CID ) " and add : The text following that seems to introduce first the idea of a " zero - length CID " , and later use that to negate the use of tlscid record . It may be more straight forward , if the " zero - length CID " is scoped to the ClientHello and the ServerHello extensions , and later the use of a tlscid record is then only caused for a non - empty CID . 
 What 's here is good , but see inline on whether we should do a little more .
Mailing list commentary: Some editorial quirks s.2 lacks the boiler plate of 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 can not 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 .. " s.4 /always recieve CIDs / always receive CIDs/ s.5.1 " the with - 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/ 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 [ , .. " 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 [ , .. " 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 [ , and renamed by RFC8447 An extra column is but I can not 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 .
Paragraph (version A):
A server willing to use CIDs will respond with a "connection_id"
extension in the ServerHello, containing the CID it wishes the client
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 (or again, alternately, to use a
zero-length CID).
Paragraph (version B):
A server willing to use CIDs will respond with a "connection_id"
extension in the ServerHello, containing the CID it wishes the client
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.
Paragraph (version A):
If DTLS peers have not negotiated the use of CIDs then the RFC
6347-defined record format and content type MUST be used.
Paragraph (version A):
If DTLS peers have negotiated the use of a CIDs using the ClientHello
and the ServerHello messages then the peers need to take the
following steps.
Paragraph (version A):
The DTLS peers determine whether incoming and outgoing messages need
to use the new record format, i.e., the record format containing the
CID.  The new record format with the the tls12_cid content type is
only used once encryption is enabled.  Plaintext payloads never use
the new record type and the CID content type.
Paragraph (version B):
If DTLS peers have not negotiated the use of CIDs, which includes the
case where both sent a zero-length cid in their connection_id
extensions, then the RFC 6347-defined record format and content type
MUST be used.
Paragraph (version B):
If DTLS peers have negotiated the use of a non-zero-length CID in at
least one direction using the ClientHello and the ServerHello
messages, then the peers need to take the following steps.
Paragraph (version B):
The DTLS peers determine whether incoming or outgoing (or both)
messages need to use the new record format, i.e., the record format
containing the CID.  The new record format with the the tls12_cid
content type is only used once encryption is enabled.  Plaintext
payloads never use the new record type and the CID content type.