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

[Jonathan Hammell <[e-mail]>]

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 <[e-mail]> 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
> 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
> 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
>
> Thanks,
> Chris, Joe, and Sean
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls