Gen-ART LC review of draft-ietf-avt-dtls-srtp-05

[Ben Campbell <ben at estacado.net>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-avt-dtls-srtp-05
Reviewer: Ben Campbell
Review Date:  2008-09-30
IETF LC End Date: 2008-10-02


Summary:

This document is almost ready for publication as a proposed standard.  
I have a point of confusion that should be addressed prior to  
publication, as well as a few nits and editorial comments.

Comments:

--Substantive Comments:

I am confused on the use of DTLS "application_data". It is not clear  
to me if this is reader error, an issue with the explanation, or a  
bona-fide protocol issue.

Section 4.1 (3rd from last paragraph) says that application data is  
never sent in DTLS record-layer "application_data" packets. However  
the last paragraph says records other than "application_data" MUST use  
normal DTLS framing and be placed in separate datagrams from SRTP  
data--this sounds like an effective contradiction to me, in that since  
SRTP packets are not "application_data" packets than they must be  
"other than application_data".

Further, section 5.1.1 paragraph 1 says that "data of type  
'application_data' ... is encrypted using SRTP rather than the  
standard TLS record encoding". I take this to mean SRTP packets _are_  
sent as "application_data",  and "...delivers it to the DTLS  
implementation as a single write of type 'application_data'", both of  
which seems to conflict with the "never sent as application_data"  
assertion in section 4.1.

Finally, 5.1.2 talks about using the first byte of the packet to demux  
RTP, DTLS, and TURN. Is this consistent with the use of  
"application_data" to distinguish SRTP packets from other DTLS packets  
described in 5.1.1? (Maybe the RTP to be demuxed here is not SRTP  
protected?)

--Nits and Editorial Comments

-Section 3, paragraph 4:

Your definition of symmetric RTP appears to assume that _both_  
endpoints are behaving symmetrically, which is a stronger requirement  
than given in the RFC 4961. It's probably worth saying that _both_  
peers must follow RFC 4961 in order to use a bi-directional session.

-Paragraph 7:

I am surprised that this is only a MAY. Would it ever make since to  
use DTLS-SRTP _without_ an external signaling protocol?

-Section 4.1, paragraph 1: "... data being transported is RTP and RTCP"

Should that be "RTP or RTCP", or possibly "one or both of RTP and RTCP"?

-First paragraph after the handshake flow diagram:

The server Certificate has a "*", but is not included in the list of  
otherwise optional parts that are always sent in DTLS-SRTP.  Do you  
intend the server Cert to be optional for DTLS-SRTP, or is this an  
error?

-section 4.1, last paragraph

It seems a bit odd to me to use a normative "MUST NOT" purely for  
clarification.

-4.1.2, last paragraph, first sentence.

I had trouble parsing this. I suggest something to the effect of "...  
must be defined according to the 'Specification Required' policy  as  
defined in RFC 5226. [RFC5226]"

--Section 9:

I've not seen normative language for IANA actions before--is this  
reasonable? In particular, I'm not sure how IANA will interpret a  
SHOULD.

References:

IDNITS reports an outdated reference for draft-ietf-tls-extractor-01.



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf