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

Hi Tom,

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

That was a discussion in 2019, see
https://github.com/tlswg/dtls-conn-id/issues/43 and follow the refered PRs.

The outcome:
If the CID is empty, RFC6347 record format is used. That's equivalent to
"empty CID is only used in the extensions of the Hellos".

Best regards
Achim Kraus

Am 12.03.21 um 18:28 schrieb tom petch:
>
> 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
>>>
>>
>> .
>>