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 On Sun, Mar 29, 2020 at 11:07 AM Hanno Becker <hanno.bec...@arm.com> wrote: > > Hi Jonathan, > > > 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. > > 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 <tls-boun...@ietf.org> on behalf of Jonathan Hammell > <jfhamme.c...@gmail.com> > Sent: Friday, March 27, 2020 5:10 PM > To: Sean Turner <s...@sn3rd.com> > Cc: TLS List <tls@ietf.org> > 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 > > 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 <s...@sn3rd.com> 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > 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
