Summary: Has enough positions to pass.
Thank you to the authors, contributors, reviewers and implementer who made this document possible.
[ section 4.4 ] * "respectively" -> "respectively." * Could a DTLS implementation packetize to a min-MTU for an IP version and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. [ section 4.5.3 ] * "MUST NOT used" -> "MUST NOT be used" [ section 5.8.4 ] * "NOT have send" -> "NOT send", I think [ section 6 ] * "which are needed to encrypt to decrypt"?
Thank you for this document. Please find some minor comments below. Francesca 1. ----- section 2. Conventions and Terminology FP: Please spell out that network byte order (most significant byte first) is used throughout the document. 2. ----- Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the server's message is lost, the client knows that either the ClientHello or the response from the server has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. FP: It would be good to mention retransmission max times here. 3. ----- | | /+----------------+\ | 31 < OCT < 64 -+--> |DTLS Ciphertext | | | |(header bits | | else | | start with 001)| | | | /+-------+--------+\ 26. The value for the "DTLS-OK" column is "Y". IANA is requested to reserve the content type range 32-63 so that content types in this range are not allocated. FP: IANA is asked to reserve 32-63, but I could not see any explanation for that. I would like to see it justified in section 4.1 or in the respective IANA section. 4. ----- fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. FP: First time PMTU appears, please expand and add reference. 5. ----- performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular: FP: I think this is missing areference to RFC 8201 since IPv6 is mentioned below. 6. ----- Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity. That is, limits MUST be specified for the number of packets that can be authenticated and for the number of packets that can fail authentication before a key update is required. Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. FP: This seems important enough that it should be highlighted for the experts reviewing the registration. I see that https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 has a number of notes, maybe that would be enough, or maybe add it (as an update?) to RFC 8447? 7. ----- zero length vector (i.e., a single zero byte length field). FP: I suggest using TLS 1.3 terminology of "zero-length vector (i.e., a zero-valued single byte length field)" 8. ----- flow shown in Figure 11 if the client does not send the ACK message FP: s/11/12
Thanks for addressing my DISCUSS, and to Gorry Fairhurst and Mark Allman for their advice on this issue.
Section 5.8.2, paragraph 1, comment: > 5.8.2. Timer Values I agree with Martin Duke's DISCUSS position (also on 5.8.3). ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. "Abstract", paragraph 1, nit: > Abstract The draft header indicates that this document obsoletes RFC6347, but the abstract doesn't seem to mention this, which it should. Section 15.1, paragraph 12, nit: > [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol > Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, > <https://www.rfc-editor.org/info/rfc8446>. > > [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol > Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, > <https://www.rfc-editor.org/info/rfc8446>. These are the same. Section 15.2, paragraph 4, nit: > [DEPRECATE] > Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and > TLSv1.1", Work in Progress, Internet-Draft, draft-ietf- > tls-oldversions-deprecate-12, 21 January 2021, > <http://www.ietf.org/internet-drafts/draft-ietf-tls- > oldversions-deprecate-12.txt>. Outdated reference: draft-ietf-tls-oldversions-deprecate has been published as RFC 8996 Section 4.2.1, paragraph 2, nit: - packet loss causes noticeable problems implementations MAY choose to + packet loss causes noticeable problems, implementations MAY choose to + + Section 5.7, paragraph 2, nit: - contains a complete list of message combinations that consitute + contains a complete list of message combinations that constitute + +
While I did review the document, I'm mostly relying on the SecADs and authors for the deep security review.
This was very well written document. Thanks for this. Minor observations below- * Section 3.1 : - Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the server's message is lost, the client knows that either the ClientHello or the response from the server has been lost and retransmits. is this supposed to mean when the timer expires the client knows either the ClientHello or the response from the server has been lost? the current text does not imply that - the server's message is lost is an interpretation of timer expired event. - The server also maintains a retransmission timer and retransmits when that timer expires. The way it is written following the previous paragraph, almost made me feel that the server is also maintaining a timer for the client hello. It would be nicer if some text explains the usage of timers at the server to break the continuous read from previous paragraph. * Section 3.3: I would add a reference to section 4.4. * Section 4.5.2: I assume the silent discard of invalid records will not impact the timers, is that a valid assumption? if yes, then it would be good if this is clarified in the text. * Section 5.8.1: Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer This is repeated twice in the section, is there any reason for that?
Thanks for the quick response and update, I've cleared my discuss. -- Thanks for the well-written document. In particular I thought it was helpful that you noted important divergences from DTLS 1.2 in line and not just at the end. COMMENTS: Section 3.1: I found the explanatory text to be confusing. You start with a figure illustrating a lost HelloRetryRequest. Then you tell me the server maintains a rexmit timer: The server also maintains a retransmission timer and retransmits when that timer expires. But then you immediately tell me that it actually doesn’t: Note that timeout and retransmission do not apply to the HelloRetryRequest since this would require creating state on the server. The HelloRetryRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloRetryRequests. I presume that if I added some more words to this, your intent is that the server maintains a retransmission timer *for messages other than HelloRetryRequest*. As written, it gave me some whiplash. Section 4.2.1: In general, implementations SHOULD discard records from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [RFC0793] to allow for packet reordering. It seems to me as though “if packet loss causes noticeable problems” is saying either too much, or not enough. Not enough: problems for whom? Noticeable by whom? How is this determined? Do you really mean I’m supposed to work this out dynamically as the text sort-of implies? Too much: if you’re not going to answer the foregoing, maybe don’t taunt me, and omit the clause entirely? Or, possibly a less vague rewrite could be in the nature of “if providing service to an application that is especially sensitive to packet loss”. NITS: Section 2: “The reader is also as to be familiar” s/as/assumed/ Section 11: Although the cookie must allow the server to produce the right handshake transcript, they “It” not “they” (agreement in number) and DTLS with connection IDs allow for endpoint addresses to change during the association; “allows” not “allow” (agreement in number)
Thank you for the work put into this document. I am afraid that I only had a quick review (lack of time). Special thanks to Sean Turner for its shepherd review containing many details about the consensus building. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3 -- s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ? Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ? -- Section 3.1 -- Should there be a hint to a maximum retry count ? -- Section 3.3 -- I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer...
Hi, Thanks for this well written document. A couple of minor suggestions: 1) Although it is clear from the metadata, it might be helpful if the introduction also stated that it obsoletes DTLS 1.2. 2) This document is a set of deltas against TLS 1.3. Given that it talks about the DTLS 1.1/1.2 documents being deltas in the introduction, I would have also included that information for this document in the introduction rather than in the Terminology and Considerations section. Initially, having read the introduction I had assumed that it was not going to be deltas. Regards, Rob