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
