ietf
[Top] [All Lists]

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

2008-10-02 22:01:50
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: draft-ietf-avt-dtls-srtp - DTLS-SRTP to Proposed Standard, Eric Rescorla <=