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

At Thu, 02 Oct 2008 17:23:31 -0400,
Russ Housley wrote:
> 
> 
> 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.

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.

> 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.

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.

> 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/

Thanks. I'll take care of these.

-Ekr
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf