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

Commentary:    review :
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):
The CID value, cid_length bytes long, as agreed at the time the
extension has been negotiated.  Recall that (as discussed
previously) each peer chooses the CID value it will receive and
use to identify the connection, so an implementation can choose to
always recieve CIDs of a fixed length.  If, however, an
implementation chooses to receive different lengths of CID, the
assigned CID values must be self-delineating since there is no
other mechanism available to determine what connection (and thus,
what CID length) is in use.
Paragraph (version B):
The CID value, cid_length bytes long, as agreed at the time the
extension has been negotiated.  Recall that (as discussed
previously) each peer chooses the CID value it will receive and
use to identify the connection, so an implementation can choose to
always receive CIDs of a fixed length.  If, however, an
implementation chooses to receive different lengths of CID, the
assigned CID values must be self-delineating since there is no
other mechanism available to determine what connection (and thus,
what CID length) is in use.
Paragraph (version A):
The following MAC algorithm applies to block ciphers that do not use
the with Encrypt-then-MAC processing described in RFC7366.
Paragraph (version B):
The following MAC algorithm applies to block ciphers that do not use
the Encrypt-then-MAC processing described in RFC7366.
Paragraph (version A):
With multi-homing, a passive attacker is able to correlate the
communication interaction over the two paths.  The lack of a CID
update mechanism in DTLS 1.2 makes this extension unsuitable for
mobility scenarios where correlation must be considered.  Deployments
that use DTLS in multi-homing environments and are concerned about
this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS
encryption is available.
Paragraph (version B):
With multi-homing, a passive attacker is able to correlate the
communication interaction over the two paths.  The lack of a CID
update mechanism in DTLS 1.2 makes this extension unsuitable for
mobility scenarios where correlation must be considered.  Deployments
that use DTLS in multi-homing environments and are concerned about
these aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to
DTLS 1.3 where a CID update mechanism is provided and sequence number
encryption is available.