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

["Dan Wing" <[e-mail]>]

> 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