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

On 12/03/2021 16:18, Achim Kraus wrote:
> Hi Tom, Hannes, Thomas,
>
> "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)."
>
> My feeling is, the text in the paragraphs following that seems to
> introduce first the idea of a "zero-length CID", and later use that only
> to negate the use of tls_cid record. It may be more straight forward, if
> the use of a "zero-length CID" is limited to the ClientHello and the
> ServerHello extensions. And later the use of a tls_cid record is then
> only for negotiated non-empty CID.
>
> WDYT?

I think that I cannot make sense of that 'alternately'.  The subsequent 
paragraphs seem to rule it out as an option.  On a first read I thought 
that a zero length CID was a valid option for Application Data and 
wanted to know which form of header and MAC was appropriate but my 
understanding of the later paragraphs became that a zero length CID can 
only appear in Hello; but I do think that this needs fixing.

I did track the WG discussion last October and did not see anything very 
clear then.

Tom Petch

> best regards
> Achim Kraus
>
>
> Am 12.03.21 um 12:58 schrieb Hannes Tschofenig:
>> Hi Tom,
>>
>> I added a few PRs to address your review (see
>> https://github.com/tlswg/dtls-conn-id/pulls).
>>
>> Regarding the zero-length CID I believe the current version in the
>> repo at https://github.com/tlswg/dtls-conn-id might have already
>> address your remark.
>>
>> In general, the zero-length CID in the ClientHello / ServerHello
>> allows us to use CIDs unidirectionally.
>>
>> Ciao
>> Hannes
>>
>> -----Original Message-----
>> From: TLS <tls-bounces@ietf.org> On Behalf Of Thomas Fossati
>> Sent: Friday, March 12, 2021 11:58 AM
>> To: tom petch <daedulus@btconnect.com>; last-call@ietf.org
>> Cc: tls@ietf.org; tls-chairs@ietf.org;
>> draft-ietf-tls-dtls-connection-id@ietf.org
>> Subject: Re: [TLS] Last Call:
>> <draft-ietf-tls-dtls-connection-id-10.txt> (Connection Identifiers for
>> DTLS 1.2) to Proposed Standard
>>
>> Hi Tom,
>>
>> Thanks very much!
>>
>> Your review is tracked in the issues below.
>>
>> On 12/03/2021, 10:39, "tom petch" <daedulus@btconnect.com> wrote:
>>>
>>> Some editorial quirks
>>>
>>> s.2
>>> lacks the boiler plate of RFC8174
>>
>> https://github.com/tlswg/dtls-conn-id/issues/88
>>
>>> 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/issues/89
>>
>>> 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/
>>
>> https://github.com/tlswg/dtls-conn-id/issues/90
>>
>>> 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/issues/91
>>
>>
>> cheers, t
>>
>>> 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 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IETF-Announce mailing list
>>>> IETF-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>> .
>>>>
>>>
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose
>> the contents to any other person, use it for any purpose, or store or
>> copy the information in any medium. Thank you.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose
>> the contents to any other person, use it for any purpose, or store or
>> copy the information in any medium. Thank you.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> .
>