John Scudder has entered the following ballot position for draft-ietf-tls-dtls13-41: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
