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

From: tom petch <[email-masked]>
Date: Fri, 12 Mar 2021 10:38:28 +0000

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
> [email-masked] mailing lists by 2021-03-28. Exceptionally, comments may
> be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 12 Mar 2021 10:58:08 +0000

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

> lacks the boiler plate of RFC8174

https://github.com/tlswg/dtls-conn-id/issues/88

> "The DTLS peers determine whether incoming or outgoing, or both,

https://github.com/tlswg/dtls-conn-id/issues/89

> /this aspects SHOULD refuse/these aspects SHOULD refuse/

https://github.com/tlswg/dtls-conn-id/issues/90

> Good information but I struggle to see what IANA will do with it; I see

https://github.com/tlswg/dtls-conn-id/issues/91

cheers, t

> > No IPR declarations have been submitted directly on this I-D.

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Mar 2021 11:58:49 +0000

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 <[email-masked]> On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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!

> s.3
> I found this unclear until I had understood it all (or perhaps I do
> not understand it)
>
> 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 "
> 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"
>
> seems not to cater for unidirectional CIDs; perhaps "The DTLS peers
> determine whether incoming or outgoing, or both, messages need.. "

> An extra column is added but I cannot see what value should be placed
> in that column for existing entries.
>
> Good information but I struggle to see what IANA will do with it; I
> see nowhere for it to go.

cheers, t

> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document: - 'Connection Identifiers for DTLS 1.2'
> > 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 [email-masked] mailing lists by 2021-03-28.
> > Exceptionally, comments may be sent to [email-masked] instead. In
> > either case, please retain the beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >

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
[email-masked]
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.

---

From: Achim Kraus <[email-masked]>
Date: Fri, 12 Mar 2021 17:18:01 +0100

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?

best regards
Achim Kraus

---

From: tom petch <[email-masked]>
Date: Fri, 12 Mar 2021 17:28:42 +0000

> only for negotiated non-empty CID.

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

>> 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.
>>
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> 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!
>>
>> 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.
>> 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.
>>

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 12 Mar 2021 18:32:19 +0000

Hi Tom, all,

On 12/03/2021, 17:29, "tom petch" <[email-masked]> wrote:
> > client's CID but does not wish the client to include a CID (or
> > again, alternately, to use a zero-length CID)."
> >
> > 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.

Is your suggestion to remove the parenthetical?  I.e.:

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

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

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

---

From: Achim Kraus <[email-masked]>
Date: Fri, 12 Mar 2021 20:33:11 +0100

Hi Tom,

 > I did track the WG discussion last October and did not see anything very

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

---

From: tom petch <[email-masked]>
Date: Sat, 13 Mar 2021 11:53:40 +0000

>     client's CID but does not wish the client to include a CID.

Thomas

Yes, that would fix this particular problem I have within this section.

I word it that way since I did raise two other doubts about the wording 
in this section in my original post, one about successful negotiation, 
which seems to me an undefined term, and one about sending and 
receiving, which seems over-restrictive in the context.

Tom Petch

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 13 Mar 2021 18:03:03 +0000

hi Tom,

On 13/03/2021, 11:54, "tom petch" <[email-masked]> wrote:
> >     again, alternately, to use a zero-length CID).
> >
> > NEW
> I word it that way since I did raise two other doubts about the
> wording in this section in my original post, one about successful
> negotiation, which seems to me an undefined term, and one about
> sending and receiving, which seems over-restrictive in the context.

At the top of the thread, you suggested to change:

>  If DTLS peers have negotiated the use of a CIDs using the ClientHello
>  and the ServerHello messages

into:

>  If DTLS peers have negotiated the use of a non-zero CID in at least
>  one direction, using the ClientHello and the ServerHello messages

which is fine with me.

However, I think it doesn't completely remove the ambiguity you are
pointing at.  So I'd suggest we also change the paragraph just above
from:

   If DTLS peers have not negotiated the use of CIDs then the RFC
   6347-defined record format and content type MUST be used.

to:

   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.

Regarding your suggestion:

> "The DTLS peers determine whether incoming and outgoing messages
> need.." seems not to cater for unidirectional CIDs; perhaps
> messages need.."

It surely works for me.

cheers, thanks!

---

From: tom petch <[email-masked]>
Date: Sun, 14 Mar 2021 14:35:16 +0000

Thomas

Yes, I agree, that is needed as well.

Tom Petch