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@xxxxxxxx> On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch <daedulus@xxxxxxxxxxxxx>; last-call@xxxxxxxx
Cc: tls@xxxxxxxx; tls-chairs@xxxxxxxx;
draft-ietf-tls-dtls-connection-id@xxxxxxxx
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@xxxxxxxxxxxxx> 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@xxxxxxxx mailing lists by 2021-03-28.
Exceptionally, comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx
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@xxxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls
