Re: [secdir] secdir review of draft-ietf-rtcweb-data-channel

[Michael Tuexen <[e-mail]>]

On 25 Oct 2014, at 00:11, David Harrington <[e-mail]> wrote:

> 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. 
Hi David,

thank you very much for your review. See my comments in-line.

Best regards
Michael
> 
> 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?
We tried to be as specific as possible.
> 
> 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.
No it doesn't. The justification is just to use the maximum number of streams. The
alternative would have been to start with some other number (which one?) and use
the extension RFC6525 to increase the number of streams, in case they are needed.
The WG decided that the process of increasing the number is too complex compared
to just negotiate the maximum number always.
> 
> 
> 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”?
Based on comments the text has been changed to

<t>Data channels are defined such that their accompanying application-level API
can closely mirror the API for WebSockets, which implies bidirectional streams
of data and a textual field called 'label' used to identify the meaning of the
data channel.</t>
> 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. 
It defines the properties of a data channel. Some of them are related to SCTP features. This is
then described. Some of them (label and protocol) are not.
I'm not sure if using RFC 2119 words would make this clearer.
> 
> 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?
This has been changed to 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?
On the sender side: Sending a larger message on one data channel will block the sending
of messages on other data channels. The impact is limited to data channels belonging to
the same peer connection.
On the receiver side: Larger messages are received. But a receiver has to deal with this anyway...
> 
> 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? 
A sender can always try to send a huge message to the receiver. But it is up to the receiver to
protect itself in some way.
> 
> Hope this helps,
> 
> David Harrington
> [e-mail]
> 
> 
>