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

[Stephen Farrell <[e-mail]>]

Hiya,

On 06/08/15 14:08, Alissa Cooper wrote:
> Picking up on one more of these ...
> 
> On Aug 5, 2015, at 10:06 AM, Stephen Farrell
> <[e-mail]> wrote:
> 
>> 
>> 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.
> 
> I am sympathetic to the point about “consent” but I’m not sure there
> is a single better word that connotes a machine agreeing to something
> rather than a person doing so. 

https://en.wikipedia.org/wiki/Clear_to_Send ?

> I think “permission” would be an even
> worse choice in this case given that it has a very common usage in
> WebRTC/browser land related to exactly what you cite above, namely
> browser permissions to use camera, mic, etc. “Willingness” seems at
> least as human if not more so than “consent.”

IMO anything that doesn't use the word consent is better than
anything that does.

To make a webrtc call a person is forced to consent to a whole
bunch of pseudo-legal crap (by their OS, browser, IdP, and
probably the web site) so entangling the protocol with any of
that is a mistake. Once you stick with the term consent, I
think such entanglement is inevitable and will be regretted.

> 
> There is already a definition of “consent” in the draft:
> 
> Consent:  The mechanism of obtaining permission from the remote 
> endpoint to send non-ICE traffic to a remote transport address. 
> Consent is obtained using ICE.
> 
> I would suggest adding one additional sentence to this:
> 
> “Note that this is an application-level consent; no human
> intervention is involved.”

That would be good enough for me to clear yes. As a comment,
I think though it'd be better as something more like:

'The only human level "consent" here is that the application
developer (e.g. WebRTC browser implementer) has programmed their
application to adhere to this specification. The actual end users
who are involved in the call have not consented to anything just
because their browser uses this protocol.'

S.


> 
> Alissa
> 
>> 
>> 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
>>>> 
>>> 
> 
>