I know these are a few hours late, but I have a few comments. I have
divided them into TECHNICAL and EDITORIAL.
TECHNICAL COMMENTS
Section 1, 2nd para. It is unclear what version of DTLS is being
used. The reference to RFC4347 in this paragraph leads to one
conclusion, but in Section 4.1.2 the authors also refer to DTLS 1.2
when discussing the PRF. If this depends on a particular version of
DTLS, please tell us up front.
Appendix B, 2nd example of Multiple DTLS Handshakes. RFC 5246,
section 7.4.1.2, states: "After sending the ClientHello message, the
client waits for a ServerHello message. Any handshake message
returned by the server, except for a HelloRequest, is treated as a
fatal error". So, looking at the second ClientHello, the server
responds with ChangeCipherSpec and Finished messages associated with
the first session. What will happen? I can imagine an
implementation that will consider it a fatal error.
EDITORIAL COMMENTS
Maybe we can avoid the possessive form of DTLS. Should it be DTLS's
be just DTLS' ?
Section 1, 3rd para, 1st sentence. s/combine/combines/
Section 1, 4th para, 3rd bullet. s/DTLS extension/DTLS extension is/
Section 3, 8th para. s/handshakes establishment exchanges./handshakes./
Section 4.1.3, 3rd para, 1st sentence. A subject is missing. I
suggest: "If the client detects a nonzero-length MKI in the server's
response that is different than the one the client offered, then the
client MUST abort the handshake and SHOULD send an invalid_parameter alert."
Section 4.2, 1st para after Figure 1, 1st sentence. s/need/needed/
Section 5.1.2, 1st para after the 5 numbered statements. s/times the
number/times the number of/
Appendix A, 2nd para, 1st sentence. s/authenticated/authenticate/
Russ
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
