Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya.

On 05/08/15 16:00, Eric Rescorla wrote:
> On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell <[e-mail]>
> wrote:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-rtcweb-stun-consent-freshness-15: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>>
>> Apologies that these discuss points are maybe asking
>> fairly fundamental questions.  That could be that this
>> is really the first of the new security things required
>> by rtcweb to get to the IESG.  Or maybe I'm misreading
>> stuff here, if so, sorry;-)
>>
>> (1) Why call this "consent?" That term is (ab)used in
>> many ways on the web, and adding another variation
>> without a definition that distinguishes this from "click
>> ok to my 200 page anti-privacy policy" or "remember that
>> example.com is allowed use my camera/mic" seems like a
>> terrible idea. I also don't see how this can ever be
>> something to which a normal person can "consent" (i.e.
>> consciously agree while fully understanding) so the term
>> is IMO very misleading, and will I fear be used to
>> mislead further.  (See also some of the comments below -
>> I do not think we ought be as fast and loose with this
>> aleady terribly badly used term.) To summarise: I'd love
>> if you did s/consent/anything-else/g but if not, please
>> define consent here in a way that clearly and
>> unambiguously distinguishes this usage from other abuses
>> of the term.
>>
> 
> You should probably propose a new term at this point.

Really? Happy to try (and fail:-) How'd "willing to take
rtcweb traffic" work? I suspect it wouldn't though.

But I'm not clear if you're agreeing that that term
is problematic or just asking me to suggest something in
the hope I realise the futility of what I'm requesting?


> 
> 
> (2) WebRTC does not require STUN or TURN servers for
>> some calls, even if it does for many. Why is it ok to
>> require such a server be present in all calls (which I
>> think this means) espcially when that means exposing
>> additional meta-data (calling parties in a case where
>> the servers weren't needed and call duration in all
>> cases) to those servers when that is not always
>> necessary?
>>
> 
> I'm not sure what you mean by "OK" and "require". 
> The physics of the
> situation
> is that if you want to do a call between two people not on the same network,
> then you minimally need STUN. 

Sure. But if they're on the same n/w? Do we agree that
in that case, there shouldn't be a need for a new STUN
or TURN server in the call? And that if this draft meant
such a server was needed even in that case, then that'd
be an issue?

> If you want it to (almost) always work you
> need TURN. This isn't a spec requirement but just a result of the network
> topology. As far as I know, the specs don't require that the site supply
> a STUN/TURN server and the implementations don't either, but I'm not
> sure what else you're looking for.

So one non-inevitable consequence of the how this draft
is written is that the STUN/TURN server gets to know the
call duration. That could have been avoided I think if
some other design had been chosen. Part of my question
then is why exposing that additional meta-data to a server
that most users won't know exists, and that is likely
controlled by some entity the user has no clue is even
involved in their calls, is acceptable.

>> (3) (end of p5) You have a MUST NOT here that is
>> depenedent on current browser implementations. Why is
>> that an IETF thing and not a W3C thing? But more
>> interestingly, can one securely use this protocol
>> without the kind of JS vs. browser sandboxing etc that's
>> needed in the web? If the answer is "no" then don't you
>> need to say that this protocol can only safely be used
>> for such implementations? (In section 2, which almost
>> but not quite says that.)
>>
> 
> This is just only relevant in this case. It doesn't apply to non-JS
> implementations.

Not sure I'm following. Are you saying that this protocol
would be safe even if there wasn't the split between JS
and non-JS code running on the browser? If so, that's good.

Cheers,
S.

> 
> -Ekr
> 
> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - abstract: why is only sending "media" mentioned here?
>> What about data channels?  And the body of the document
>> in fact says this all applies to any non-ICE data and
>> not only media.
>>
>> - intro: "initial consent to send by performing STUN" I
>> do not find the word consent in either rfc5245 or 3489,
>> but perhaps it is used somewhere else. Where?  And with
>> what meaning?
>>
>> - section 4, 2nd last para - I think the conclusion is
>> bogus.  An implementation knows when the keying it's
>> using can not involve >1 (nominally operating) party.
>>
>> - 5.1, 3rd para: "Explicit consent to send is
>> obtained..." is misleading. That is not a concept that
>> an implementation of STUN will embody.
>>
>> - 5.1, What is the "Note" about TCP for? Why is this
>> needed?
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>