Skip to main content

Last Call Review of draft-ietf-rtcweb-data-channel-12

Request Review of draft-ietf-rtcweb-data-channel
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-28
Requested 2014-10-16
Authors Randell Jesup , Salvatore Loreto , Michael Tüxen
I-D last updated 2014-10-30
Completed reviews Genart Last Call review of -12 by Vijay K. Gurbani (diff)
Secdir Last Call review of -12 by David Harrington (diff)
Assignment Reviewer David Harrington
State Completed
Request Last Call review on draft-ietf-rtcweb-data-channel by Security Area Directorate Assigned
Reviewed revision 12 (document currently at 13)
Result Has issues
Completed 2014-10-30

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I think this document is not ready.

A few comments.

1) This proposal stacks a number of protocols - SCTP/DTLS/ICE - with which I am
not intimately familiar.

I cannot tell whether using these in combination opens any holes.

2) one of the use cases pertains to avoiding internet filtering and monitoring
of HTTP messages.

From a security perspective, I find this undesirable, but it is probably a real
world use case.

3) This document has dependencies on 8 different internet drafts -

features in [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported.

features in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.

[I-D.ietf-rtcweb-jsep] will establish the connection,

and so on …

It is hard to assess the security of the system when so many pieces are yet to
be “fixed”. Security is a process.

While this could be put through with downlinks, I think it important to
understand how those pieces fit with this document to create system, before
this part should be approved.

4) section 6.2 specifies some sentences using “will”; I think to make the
standard unambiguous, these should be converted into RFC2119 keywords.

5) section 6.2 says "typically this will be shared via BUNDLE or equivalent


. Without knowing what will be used, it is difficult to assess the security

This is being submitted as standards-track, and I think the


 needs to be tightened up considerably to determine whether an implementation
 is standard-compliant. Which of these


 are mandatory to implement for compliance, and which are optional?

6) section 6.2 says "

The number of streams negotiated during SCTP association setup SHOULD

   be 65535, which is the maximum number of streams that can be
   negotiated during the association setup.” It is unclear to me whether the
   following paragraphs explain why the maximum number of streams should be
   negotiated. If so, then I think this should be made clearer. If not, then I
   think a justification for negotiating the maximum should be provided.

7) section 6.4 says “A strong wish if for

the application-level API to be close to the

   API for WebSockets ...”; Can I assume that by


close to


 the authors mean


similar to



I think the text in 6.4 needs to be

tightened, using RFC2119 keywords.

“each data channel has the following properties …”; I cannot tell whether this
is defining properties that must be implemented or is a description of the
properties that happen because this proposal uses SCTP.

8) 6.5 saya "

If it attempts to re-use a stream which is part of an

existing data channel, the addition SHOULD fail.” I have a concern that this is
not a MUST. Are there security implications if this is not a MUST?

9) 6.6 again


 use some RFC2119

keywords. I think the whole section should be looked at for keywords, but have
particular concern about error handling and die limitations. If an implementer
ignores the SHOULD limit to 16KB, what impact both from an operational
perspective and a security perspective will this have?

10) I don


t think pointing to a generic rtcweb security document is sufficient. The
security considerations section in this document should discuss the security
implications of various implementation choices specific to this document. There
are a number of SHOULDs in this document. What are the security implications of
not applying the SHOULD,? see my point #9, for example. Could this be


 to create a DOS attack?

Hope this helps,

David Harrington

ietfdbh at