Last Call Review of draft-ietf-rtcweb-data-channel-12
review-ietf-rtcweb-data-channel-12-secdir-lc-harrington-2014-10-30-00

Hi,

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

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

language

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

options

 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

could

 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

exploited

 to create a DOS attack?

Hope this helps,

David Harrington

ietfdbh at comcast.net