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

Michael Tuexen <> Tue, 13 May 2014 16:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB98F1A00DD for <>; Tue, 13 May 2014 09:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qUGIVpl_TEpT for <>; Tue, 13 May 2014 09:23:45 -0700 (PDT)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 6DB2A1A00E3 for <>; Tue, 13 May 2014 09:23:44 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: macmic) by (Postfix) with ESMTP id BDDC41C1047F4; Tue, 13 May 2014 17:51:35 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Tue, 13 May 2014 17:51:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.1874)
Cc:, "" <>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 May 2014 16:23:48 -0000

On 13 May 2014, at 17:26, Magnus Westerlund <> wrote:

> Hi,
> Please see inline.
> On 2014-05-13 08:29, Michael Tuexen wrote:
>> On 15 Apr 2014, at 17:55, Magnus Westerlund <> wrote:
>>> On 2014-04-10 13:50, Michael Tuexen wrote:
>>>> On 04 Mar 2014, at 17:39, Magnus Westerlund <> wrote:
>>>>> On 2014-02-25 17:07, Michael Tuexen wrote:
>>>>>> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund <> 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.
Randell and Salvatore also think it makes sense to use an unsigned int.
I'll change that.
>>>>>>> 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.
Isn't this be said by the first sentence of the paragraph? It states
the requirement of having a rule and provides on the second sentence
such a rule for the case where DTLS is used.

Best regards
>>>>>>> 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  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------