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

On 04/30/2012 09:16 AM, Magnus Westerlund wrote:
> 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.

(speaking as use case doc editor): makes a lot of sense to me.

>
> Cheers
>
> Magnus
>
>
> On 2012-04-27 18:48, Dan Wing wrote:
>>> 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
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>