Subject: Last Call: draft-ietf-avt-dtls-srtp - DTLS-SRTP to Proposed Standard

From: Russ Housley <[email-masked]>
Date: Thu, 02 Oct 2008 17:23:31 -0400

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 02 Oct 2008 19:00:08 -0700

At Thu, 02 Oct 2008 17:23:31 -0400,
> DTLS, please tell us up front.

No, it doesn't depend. It's compatible with either version of DTLS.
However, because DTLS has adjustable PRFs, we simply added
this sentence to make clear what to do with DTLS 1.2.

> implementation that will consider it a fatal error.

The text you're referring to in RFC 5246 refers to a single connection,
but Appendix B is talking about two separate connections/associations
(hence the (1) and (2)). This is not an error in TLS. In fact,
in this particular case the state machines are completely uncoupled.

> Appendix A, 2nd para, 1st sentence. s/authenticated/authenticate/

Thanks. I'll take care of these.

-Ekr