Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03

[Magnus Westerlund <[e-mail]>]

Hi,

Please see inline.

On 2014-05-13 08:29, Michael Tuexen wrote:
> On 15 Apr 2014, at 17:55, Magnus Westerlund <[e-mail]> wrote:
>> On 2014-04-10 13:50, Michael Tuexen wrote:
>>> On 04 Mar 2014, at 17:39, Magnus Westerlund <[e-mail]> wrote:
>>>> On 2014-02-25 17:07, Michael Tuexen wrote:
>>>>> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund <[e-mail]> wrote:
>>>>>> 1. Section 4:
>>>>>> Shouldn't this section discuss the priority field?
>>>>> I added in the list of consistent properties:
>>>>>
>>>>> <t>the priority of the data Channel.</t>
>>>>>
>>>>> and in the text below that enumeration:
>>>>>
>>>>> ??????
>>>>
>>>> Yes, text for this needs to be figured out.
>>> We don't define at this place what priority is. The only point is that both
>>> sides use the same priority.
>>
>> Okay, I agree, the Priority is a property of the established Data
>> Channel, and the values and implication of these needs to be defined in
>> the Data Channel draft and not here.

> OK. The only thing we might want to change in this ID is the type of the
> Priority field. It is currently a signed integer, we might want to use
> an unsigned integer. But that is a different issue, which I'll need to
> discuss with Randell.

Ok, lets try to get the Priority part resolved so that the appropriate
type and pointer can be get included here.

>>
>>>>
>>>>>>
>>>>>> 2. Section 4:
>>>>>>
>>>>>> The method
>>>>>> used to determine which side uses odd or even is based on the
>>>>>> underlying DTLS connection role when used in WebRTC, with the side
>>>>>> acting as the DTLS client using even stream identifiers.
>>>>>>
>>>>>> Isn't this unnecessary using the vague word of WebRTC instead of simply
>>>>>> pointing to the DTLS roles of the established data channel?
>>>>
>>>>> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore
>>>>> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP
>>>>> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS.
>>>>> In that case DTLS is not used and you can not refer to the DTLS role.
>>>>> That is why the restriction is used.
>>>>
>>>> Ok, if that concern then you still should be able to write a normative
>>>> specification under the condition that it is SCTP over DTLS. If not how
>>>> do you determine that? Are suggesting just to hand way or point to a
>>>> higher signaling layer.
>>> So what about using:
>>>
>>> when using <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, the method used to
>>> determine which side uses odd or even is based on the underlying DTLS
>>> connection role: the side acting as the DTLS client MUST use Streams with even
>>> SCTP stream identifiers, the side acting as the DTLS server MUST use Streams
>>> with odd SCTP stream identifiers.</t>
>>
>> I think that is fine for when using over DTLS. And to my understanding
>> this do require DTLS? If not we need alternative text.

> Our current use-case is for SCTP/DTLS. But we don't need DTLS except for
> its security properties. However, if someone doesn't use DTLS, he has to
> figure out how to determine the even/odd. This is covered by:
> 
> <t>To avoid glare in opening Channels, each side MUST use Streams with 
> either even or odd SCTP stream identifiers when sending a DATA_CHANNEL_OPEN
> message.
> When using <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, the method used to
> determine which side uses odd or even is based on the underlying DTLS
> connection role: the side acting as the DTLS client MUST use Streams with even
> SCTP stream identifiers, the side acting as the DTLS server MUST use Streams
> with odd SCTP stream identifiers.</t>
> 
> However, we can't provide a method in the general case...

Yes, as long as you use DTLS it is well specified. The issue I am trying
to get my head around is if this specification and the data channel is
possible to use without DTLS. This is one of the few (only?) things that
requires it beyond the security features. Thus, should this be
explicitly noted as saying, if you don't use DTLS you will be required
to find an alternative solution to the roles.



>>
>>>>
>>>>>
>>>>>> 6. Section 7:
>>>>>>
>>>>>> I think this section can be beefed up a bit. First make clear that the
>>>>>> Data Channel's required usage of DTLS ensures that the message integrity
>>>>>> and possible source authentication as well as confidentiality. Then
>>>>>> going over any security risks with a malicous peer using this protocol.
>>>>>> Can a malicous side screw up the peer using this protocol? What are the
>>>>>> implications?
>>>>
>>>>> Just to double check: Aren't the referenced documents the ones which
>>>>> discuss all security stuff in one place?
>>>>
>>>> The security document do discuss system level important aspects. But,
>>>> from my perspective, details that are very specific to this protocol
>>>> should be discussed in this document.
>>>>
>>>> I think this is highly relevant in this document as there are others
>>>> that are interested in using it.
>>> OK. Any concrete suggestions what should be covered?
>>
>> I can at least think of potentially relevant issues:
>>
>> - Exhaustion attacks by opening all 64k Data channels
> You setup 64k streams anyway and it wasn't a problem...
>> - Attempting to overflow buffers by including 64k of Strings in Label
>> and Protocol fields in the OPEN message.
> OK.
>> - Attempt to get undocumented behaviour by sending Reliability
>> Parameters that aren't defined. Or use out of range Priorities or
>> message types.
> This is also covered explicitly in the Procedures section by
> 
> <t>If a DATA_CHANNEL_OPEN message is received on an already used SCTP stream or
> there are any problems with parameters within the DATA_CHANNEL_OPEN message or
> the DATA_CHANNEL_OPEN message itself is not well-formed,
> the receiver MUST close the corresponding channel using the procedure described
> in <xref target='I-D.ietf-rtcweb-data-channel'/> and MUST NOT send a
> DATA_CHANNEL_ACK message in response to the received message.
>>
>> But that I guess is most of the things I can think of to attempt to
>> break the protocol.
> I agree.
>>
>> Then it is the question of requiring DTLS to ensure it is safe from
>> Privacy, Confidentiality, Integrity and possibly source authentication
>> concerns.
> Sure.
> 
> So what about the following Security Considerations section:

> <t>The DATA_CHANNEL_OPEN messages contains two variable length fields:
> the protocol and the label. A receiver must be prepared to receive
> DATA_CHANNEL_OPEN messages where these field have the maximum length of
> 65535 bytes. Error cases like the use of inconsistent lengths fields,
> unknown parameter values or violation the odd/even rule must also be handled
> by closing the corresponding channel. An end-point must also be prepared
> that the peer open the maximum number of data channels.</t>

Maybe: "peer open" / "peer attempts to open"

> <t>When using DCEP over SCTP encapsulated in DTLS as specified in
> <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, security properties
> like privacy, integrity, and source authentication can be provided by DTLS.
> If DCEP is used without running over DTLS, this is not the case.</t>

You skirt around the issue if you are mandating DTLS or not. One
interesting question here is if this is one case where DTLS shall be the
mandatory to implement security solution, or if it is okay to leave it
open to redefention in the different contexts, as in the case of WebRTC
the transports draft will mandate the inclusion of DTLS.

Then the next step is the question of which DTLS ciphers and
key-derivation methods that shall be supported. This later is likely an
pointer to the security-arch.

> <t>For general considerations see <xref target='I-D.ietf-rtcweb-security'/> and
> <xref target='I-D.ietf-rtcweb-security-arch'/>.</t>

> 
> Does this address your issues?

Mostly, thanks for the proposal.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------