Re: [TLS] Last Call: <draft-ietf-tls-dtls-connection-id-10.txt> (Connection Identifiers for DTLS 1.2) to Proposed Standard

[tom petch <[e-mail]>]

Some editorial quirks

s.2
lacks the boiler plate of RFC8174

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

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/

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.

Tom Petch


On 08/03/2021 11:19, The IESG wrote:


>
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'Connection Identifiers for DTLS 1.2'
>    <draft-ietf-tls-dtls-connection-id-10.txt> 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
> [e-mail] mailing lists by 2021-03-28. Exceptionally, comments may
> be sent to [e-mail] 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.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>