Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Tue, 13 May 2014 16:23 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB98F1A00DD for <rtcweb@ietfa.amsl.com>; Tue, 13 May 2014 09:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUGIVpl_TEpT for <rtcweb@ietfa.amsl.com>; Tue, 13 May 2014 09:23:45 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2A1A00E3 for <rtcweb@ietf.org>; Tue, 13 May 2014 09:23:44 -0700 (PDT)
Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (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 <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <537239AD.9040000@ericsson.com>
Date: Tue, 13 May 2014 17:51:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <980A88B9-5DBB-4A96-8F3F-4F77D64BE22C@lurchi.franken.de>
References: <530B740E.4090707@ericsson.com> <B163D4A9-AC33-454B-8F93-CC619AFB7A6F@lurchi.franken.de> <53160FBB.4070401@ericsson.com> <1904CA30-1112-44D4-8C6F-F15F1EF1BF9B@lurchi.franken.de> <534D566B.3040905@ericsson.com> <FB076F4A-83D9-4109-9FDC-89A4A2712553@lurchi.franken.de> <537239AD.9040000@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UfEXtToswLVXxnlnzHOKYjYSEtQ
Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 16:23:48 -0000
On 13 May 2014, at 17:26, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > Hi, > > Please see inline. > > On 2014-05-13 08:29, Michael Tuexen wrote: >> On 15 Apr 2014, at 17:55, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: >>> On 2014-04-10 13:50, Michael Tuexen wrote: >>>> On 04 Mar 2014, at 17:39, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: >>>>> On 2014-02-25 17:07, Michael Tuexen wrote: >>>>>> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> 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 Michael > > > >>> >>>>> >>>>>> >>>>>>> 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: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > >
- [rtcweb] Review comments on draft-ietf-rtcweb-dat… Magnus Westerlund
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Magnus Westerlund
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Paul Kyzivat
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Paul Kyzivat
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Paul Kyzivat
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Magnus Westerlund
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Magnus Westerlund
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Magnus Westerlund
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Magnus Westerlund
- Re: [rtcweb] Review comments on draft-ietf-rtcweb… Michael Tuexen