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


Maybe something between the two.




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


Yes.



> And that if this draft meant
> such a server was needed even in that case, then that'd
> be an issue?


Yes, I think it shouldn't require that.


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


This isn't correct. The STUN server doesn't know and the TURN server only
knows if the relay candidate is slected.




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


I don't understand what you are concerned about here.




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

I'm saying that the primary concern of this document is that attackers
will force people's Web browsers to spam other people with RTP traffic
and that that isn't as big an issue in non-Web contexts, which is why
we don't do continuing consent for (say) SIP + ICE.

-Ekr


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