Subject: [rtcweb] use cases, F20 and encryption, SCTP - comments on draft-ietf-rtcweb-use-cases-and-requirements-07

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Apr 2012 09:48:57 -0700

> The chairs would like to ask the working group to focus on the use
> case draft.  If you have use cases that need to be added to the
> document or text changes you'd like to suggest, please send them in
> for discussion before May 15th.  After this round, we will look
> toward having a working group last call on the document (hopefully
> before the interim meeting).

A few comments on draft-ietf-rtcweb-use-cases-and-requirements-07:

1. Requirement F20 states:

   F20  It MUST be possible to protect streams from eavesdropping.

Consensus in the room during my presentation to RTCWEB at IETF83 was that we
don't need to support un-encrypted media (RTP) at all, and that all media
would be SRTP.  Can that be captured in F20 by re-wording, or perhaps in a
new requirement if we can't reword F20?  If there is a need or desire to
validate that consensus on list, let's please ask the chairs to do that.

2. I noticed there is no requirement that we have a baseline for how SRTP
media is keyed (although there is a baseline requirement for codecs).  This
is a critical requirement.  I suggest adding "The browser MUST support a
baseline SRTP keying mechanism."  We have not reached consensus on that
keying mechanism, but the requirement is real.

3. I see the document restricts its scope to media streams in the
Introduction with:

  "The document focuses on requirements related to real-time media
   streams.  Requirements related to privacy, signalling between the
   browser and web server etc. are currently not considered."

However, RTCWEB is also supports a data communication between browsers.  I
am worried if we do not specify requirements for the data communication we
will have problems.  I believe the expectation is that if the audio/video
stream works, that the data communication stream also work.  We need to
capture requirements for the data communication stream somewhere:

  - a requirement to support data communication
  - that the chosen data communication protocol supports multiple streams
(which is why SCTP was chosen over TCP)
  - for NAT/firewall traversal of the data communication protocol (which is
why SCTP-over-UDP was chosen and another reason TCP was not chosen)
  - for encrypting that data communication session
  - a requirement for SCTP-over-UDP to work when UDP is blocked (aligning
with the existing F29 for audio/video)
  - a requirement to do ICE connectivity checks prior to bringing up DTLS (I
don't know if that is really a requirement, but I recall it mentioned at the
RTCWEB interim in Mountain View).  

Based on the scoping of the draft-ietf-rtcweb-use-cases-and-requirements,
the omission of the data communication stream is intentional.  If not in
draft-ietf-rtcweb-use-cases-and-requirements, where can we capture the
requirements for the data communication stream?

-d

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 27 Apr 2012 09:58:00 -0700

> keying mechanism, but the requirement is real.

On the contrary, the conclusion of the consensus call in 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04125.html said: 
"...no one objected against making DTLS-SRTP a mandatory to implement 
and the default keying mechanism."

Regardless of the debate over SDES, that sounds like we have _a_ 
baseline SRTP keying mechanism.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Apr 2012 23:10:54 +0200

>     browser and web server etc. are currently not considered."
It seems that the intro is inconsistent with the rest of the document, then.
The following requirements all require non-media browser-to-browser streams:

    F23             The browser must be able to send short
                    latency datagram traffic to a peer browser
    ----------------------------------------------------------------
   A18             In addition to the streams listed elsewhere,
                    the Web API MUST provide a mechanism for sending
                    and receiving isolated discrete chunks of data.
    ----------------------------------------------------------------

These are both derived from use case 4.2.11, "Multiparty on-line game 
with voice communication".

>    - a requirement to support data communication
Present
> (which is why SCTP was chosen over TCP)
I'm not sure what scenario would support that - the discussion so far 
seemed to hinge on the idea that people would need multiple streams no 
matter what, so we'd either have multiple streams in the protocol, or 
people would invent their own multiplexing scenarios on top of what we 
provided.
> with the existing F29 for audio/video)
This one I'm sure we need to discuss more. SCTP-over-DTLS-over-TURN?
> RTCWEB interim in Mountain View).
I think this one is chiefly an implementation strategy to achieve the 
security requirements outlined in the -security draft.
> requirements for the data communication stream?
I think the scoping needs rewording.
> -d
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Randell Jesup <[email-masked]>
Date: Fri, 27 Apr 2012 22:55:49 -0400

> capture requirements for the data communication stream somewhere:

This is a surprise to me; I thought data channels (in some form) were 
always part of the requirements.  It seems like they got abstracted a 
bit in editing - 4.2.11 (online game with voice) covers it, and it still 
says "Quick updates of the game state is [sic] required".  This used to 
be F20, and is now F23

F23  The browser must be able to send short latency datagram traffic to a peer browser

However, I agree this is rather too vague, but I think we wanted to 
leave open one stream vs multiple, reliable vs not (though latency 
implies unreliable), etc.

>    - a requirement to support data communication

Covered by F23

> why SCTP-over-UDP was chosen and another reason TCP was not chosen)

Implied by F23, F19 says "Streams MUST be able to pass through 
restrictive firewalls" -- not "Media streams", and F2 says   "The 
browser MUST be able to send streams to a peer in the presence of NATs."

The requirements use "streams", "audio streams", "video streams" and 
"media streams".  Some uses of plain "streams" only make sense for 
media; others can obviously make sense for media or data.

>    - for encrypting that data communication session

F20 says "It MUST be possible to protect streams from eavesdropping".  
Again, if "streams" includes data streams, it's already covered.  If 
not, then yes, this should be a requirement.

> with the existing F29 for audio/video)

Ditto again the "streams" remark.

> requirements for the data communication stream?

I'm pretty certain it wasn't intentional, given F23 (which has been 
there since the start), and that was the understanding of the 
participants, I would assert.

I agree it could use fleshing out (and the other requirements could use 
more consistent uses of "streams" to avoid confusion).

-- 
Randell Jesup
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Apr 2012 20:51:05 -0700

> validate that consensus on list, let's please ask the chairs to do that.

This requirement probably requires a bit more examination.  I tend to
agree that something more specific regarding SRTP would be good, but
that doesn't cover the whole story.

SRTP alone doesn't protect against the site (or sites).  If there is
mutual authentication, then it might be possible to prevent an
application from being able to eavesdrop (conditional on some degree
of trust in the identity provider).

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Apr 2012 09:16:27 +0200

Hi,

My suggestion is that the use case document should be clarified. And I
think the starting point is that the data channel must have the same
security requirements as RTP media, both are media from the point of the
application.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------