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