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

[Eric Rescorla <[e-mail]>]

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.


(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. 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.




> (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.

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