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(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf