Subject: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

From: Sean Turner <[email-masked]>
Date: Fri, 20 Mar 2020 10:17:18 -0400

This is the third working group last call for the "The Datagram Transport
Layer Security (DTLS) Protocol Version 1.3" draft available at
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ <https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/>. Please
review the document and send your comments to the list by 2359 UTC on
27 March 2019.

This is a targeted one-week WGLC intended to focus on the changes from -34, which was the subject of the second working group last call, and -37. The diffs between -34 and -37 can be found at:
https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-34&url2=draft-ietf-tls-dtls13-37 <https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-34&url2=draft-ietf-tls-dtls13-37>
As you will see in the diffs, the changes include 2119-language related changes in s5.1 and s7. These two changes were introduced in -35, which was post in November.

Note the the GH repo for this draft can be found at:
https://github.com/tlswg/dtls13-spec <https://github.com/tlswg/dtls13-spec>

Thanks,
Chris, Joe, and Sean

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 27 Mar 2020 13:10:02 -0400

I know that this WGLC was supposed to focus on the diff between -34
and -37.  I don't have any comments on that diff, but I do have some
comments on the draft following a re-read of the entire document.

# Minor

The term "deprotection" is used twice in document but never defined.

Section 5.11 abandoning vs destroying association.  In the document we
see the term "abandon" being used, referring to associations. However
section 5.11 states that a server "MUST NOT destroy the existing
association" and then further along it states that "the server MUST
abandon the previous association". Do abandon and destroy mean the
same thing?

In Section 7, what does "handshake-containing" mean in the phrase "The
ACK message is used by an endpoint to indicate
handshake-containing..."?

In Section 7, what does "non-duplicative" mean in phrase
"Implementations MUST NOT acknowledge records containing
non-duplicative handshake messages..."?

In Section 7.1, the 2nd bullet following para 1 reads: "When they
receive a message or fragment which is out of order, either because it
is not the next expected message or because it is not the next piece
of the current message. Implementations MUST NOT send ACKs for
handshake messages which they discard as
out-of-order, because otherwise those messages will not be retransmitted."
This is confusing as the difference between "out of order" messages
that require an ACK and those that do not is not quite clear. Also the
term "out of order" is written in two ways in this paragraph.

In Figure 10, the edge going from SENDING to FINISHED has no label to
differentiate with edge to WAITING. Should it read: "send last
flight"?

In Figure 13, why is there no NewConnectionID message in the exchanges
since new CIDs are offered?  Also, a short explanation of the CID
negotiation and exchange could be helpful in the text.

The state machine in Figure 10 is somewhat puzzling.  How do we
differentiate between "Receive ACK for last flight" and "Receive last
flight"? According to Figure 7, for example, the last ACK is a flight
itself.  Also, with respect to the client, if sending last flight
takes him to finished state, how will he then receive the ACK for his
final flight?

# Nits

Section 3.1 Packet Loss.  Figure 1 is a little confusing since it
resembles Figure 5; as each has the server sending a
HelloRetryRequest. Might illustrate the concept better to have the
server send a ServerHello in Figure 1 rather than a HelloRetryRequest?

Section 5.1. para 3 - Typo.  "The DTLS 1.3 specification changes the
way how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses
the HelloRetryRequest message". The "... the way how cookies..."
either use "how" or "the way" but not both.

Page 9 last para - Typo.  s/assocatiation/association

In section 3, bullet #3, the term "flight" is used without being
defined; a reference to section 5.6 would be nice.

MSL is used first in section 4.2.1 but only defined in section 5.7.1

In section 5.11 the notion of "CID concept" is mentioned. Might be
nice to refer to section 9.1 where an example of the concept is
presented. Also, section 9.1 never mentions "CID concept"; might be
good to add the term to know that we are talking about the same
thing.

Figure 11 has no commentary describing the sequence. It would be helpful, for
example, to add details on why the two ACKs are sent.

In Section 6.1, the phrase "...loss and re-order an identifier is needed to
determine..." could use a comma after "re-order" and possibly replace
"re-order" with "re-ordering".

In Section 6.1, the phrase "In addition to the key derivation steps
described in Section 7 of [TLS13] triggered by the states during the
handshake a sender may want to rekey at any time during the lifetime
of the connection and has to have a way to indicate that it is
updating its sending cryptographic keys" is long and difficult to
follow.  It could be rephrased as "In addition to
the key derivation steps described in Section 7 of [TLS13], a sender
may want to rekey at any time during the lifetime of the connection.
The epoch value provides a means to indicate that the sender is
updating its sending cryptographic keys."

In Section 6.1, replace "For example, client incorrectly uses..." with
"For example, if a client incorrectly uses..."

In Section 7, the term "current key" is used in the phrase
"Implementations SHOULD simply use the current key."  Would it be
clearer to say that "Implementations SHOULD use the key material of
the current epoch"?

In Section 8, paragraph 3, what does a "canned ACK message" mean?

Section 11, second para, s/Even with such a test, An/Even with such a test, an

Section 11, third bullet: the statement "...DTLS 1.3 records
irrespectively of the use of a CID" could be rephrased as "...DTLS 1.3
records irrespective of whether a CID is used or not."

On Fri, Mar 20, 2020 at 10:18 AM Sean Turner <[email-masked]> wrote:
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-34&url2=draft-ietf-tls-dtls13-37
> https://github.com/tlswg/dtls13-spec
>
> Thanks,
> Chris, Joe, and Sean
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 29 Mar 2020 09:17:03 +0000

Hi Jonathan,

Thanks for carefully reading the spec and for your feedback.

Let me quickly respond to some of your comments.

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Jonathan Hammell
Sent: Friday, March 27, 2020 6:10 PM
To: Sean Turner <[email-masked]>
Cc: TLS List <[email-masked]>
Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

I know that this WGLC was supposed to focus on the diff between -34 and -37.  I don't have any comments on that diff, but I do have some comments on the draft following a re-read of the entire document.

# Minor

[Hannes] Looking at the text I believe we can just remove the term.
Here is the PR: https://github.com/tlswg/dtls13-spec/pull/129

~snip~

# Nits

Section 3.1 Packet Loss.  Figure 1 is a little confusing since it resembles Figure 5; as each has the server sending a HelloRetryRequest. Might illustrate the concept better to have the server send a ServerHello in Figure 1 rather than a HelloRetryRequest?

[Hannes] I changed Figure 1, as suggested. Note, however, there is nothing wrong with the figures as they are because these two sections describe different concepts. Figure 1 talks about packet loss and retransmissions while Figure 5 is about the cookie exchange.

PR is here: https://github.com/tlswg/dtls13-spec/pull/130 and for the wording changes below I have created another PR here: https://github.com/tlswg/dtls13-spec/pull/131

Section 5.1. para 3 - Typo.  "The DTLS 1.3 specification changes the way how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message". The "... the way how cookies..."
either use "how" or "the way" but not both.

[Hannes] OK.

[Hannes] Fixed.

In section 3, bullet #3, the term "flight" is used without being defined; a reference to section 5.6 would be nice.

[Hannes] I changed the sentence to omit the term 'flight' to avoid the forward reference to Section 5.6 in the overview.

[Hannes] I added MSL to the terminology section.

In section 5.11 the notion of "CID concept" is mentioned. Might be nice to refer to section 9.1 where an example of the concept is presented. Also, section 9.1 never mentions "CID concept"; might be good to add the term to know that we are talking about the same thing.

[Hannes] I removed the term concept and added a sentence to the terminology.

In Section 6.1, the phrase "...loss and re-order an identifier is needed to determine..." could use a comma after "re-order" and possibly replace "re-order" with "re-ordering".

[Hannes] Ok.

In Section 6.1, the phrase "In addition to the key derivation steps described in Section 7 of [TLS13] triggered by the states during the handshake a sender may want to rekey at any time during the lifetime of the connection and has to have a way to indicate that it is updating its sending cryptographic keys" is long and difficult to follow.  It could be rephrased as "In addition to the key derivation steps described in Section 7 of [TLS13], a sender may want to rekey at any time during the lifetime of the connection.
The epoch value provides a means to indicate that the sender is updating its sending cryptographic keys."

[Hannes] I re-worded the sentence.

In Section 6.1, replace "For example, client incorrectly uses..." with "For example, if a client incorrectly uses..."

[Hannes] OK.

In Section 7, the term "current key" is used in the phrase "Implementations SHOULD simply use the current key."  Would it be clearer to say that "Implementations SHOULD use the key material of the current epoch"?

[Hannes] Fine for me.

[Hannes] Fixed.

Section 11, third bullet: the statement "...DTLS 1.3 records irrespectively of the use of a CID" could be rephrased as "...DTLS 1.3 records irrespective of whether a CID is used or not."

[Hannes] Fixed.

Ciao
Hannes

On Fri, Mar 20, 2020 at 10:18 AM Sean Turner <[email-masked]> wrote:
>
> This is the third working group last call for the "The Datagram
> Transport Layer Security (DTLS) Protocol Version 1.3" draft available
> at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-34&url2=draft-
> ietf-tls-dtls13-37 As you will see in the diffs, the changes include
> 2119-language related changes in s5.1 and s7. These two changes were introduced in -35, which was post in November.
>

_______________________________________________
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: Hanno Becker <[email-masked]>
Date: Sun, 29 Mar 2020 15:07:01 +0000

Hi Jonathan,

> term "out of order" is written in two ways in this paragraph.

On second read, I agree that this is confusing. The point is that
while, to my understanding, out-of-order messages should trigger
the transmission of an ACK acknowledging what has been processed
so far, the out-of-order messages themselves must not be included
in those ACKs unless they have been buffered.

In more detail, there are two kinds of feedback signals from the
handshake layer to the record layer:

1. Signal whether there is some disruption in the incoming flight
   which the peer should be informed about via an ACK of those
   messages received and processed so far.

   That's what the first sentence in the above quote is about.

2. Signal whether a handshake message has been processed.

   That's what the second sentence in the above quote is about,
   which can also be rephased as follows:
   An ACK must only be sent for those records which consist of
   handshake messages each of which has been signalled as
   processed by the handshake layer.

   In particular, in situations where a single record contains
   multiple handshake messages/fragments, and the implementation
   processes only some of them, the record must not be acknowledged.
   A real-world example for this would be an implementation which
   supports out-of-order buffering but only contiguous reassembly:
   If the initial fragment of a HS message gets sent in one record
   which is lost, and the final fragment together with a subsequent
   handshake message is sent in another record, then this latter
   record must not be ACKed if the stack drops the fragment.

Unbuffered out-of-order handshake messages do trigger signal 1,
but they don't trigger signal 2.

At least, that's my understanding.

Best,
Hanno
________________________________
From: TLS <[email-masked]> on behalf of Jonathan Hammell <[email-masked]>
Sent: Friday, March 27, 2020 5:10 PM
To: Sean Turner <[email-masked]>
Cc: TLS List <[email-masked]>
Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

# Minor

# Nits

---

From: Jonathan Hammell <[email-masked]>
Date: Mon, 30 Mar 2020 09:54:28 -0400

Hi Hanno,

Thank you for your clarifications.  The example you gave helps a lot.
I believe I now understand the text as written in this bullet (first
bullet, not second--my bad).  I no longer think it needs re-wording.

Best regards,
Jonathan