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

[Alissa Cooper <[e-mail]>]

Thanks Stephen, responding to a couple points below where others have not chimed in yet.

On 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.
> 
> (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? 
> 
> (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.)
> 
> (4) Section 8: Where are these 96 bits defined? I think
> this "requires..." statement needs a precise reference
> to the place in some ICE/TURN/STUN RFC where it's
> defined. (And I forget where that is, sorry:-) This
> should be an easy fix.

https://tools.ietf.org/html/rfc5389#section-6 (as referenced in Section 5.1)

> 
> (5) Why is it ok to approve this while the
> rtcweb-security-arch and rtcweb-security are still
> developing? There are section-specific references here
> along the lines of: "doing this is ok because of section
> x.x" of both of those drafts. Why is it ok to approve
> this now, when the underlying architecture and overall
> security model on which this depends are still in-flux?
> I'm not asking about editorial changes here nor about
> timing, but about why it's ok to approve this when the
> basic security concepts have yet to undergo IETF last
> call, and so could change significantly.

I think it’s worth looking at what the cross-references actually point to.

Section 2 says:

"Section 4.4 and Section 5.3 of
   [I-D.ietf-rtcweb-security-arch] further explains the value of
   obtaining and maintaining consent.”

Section 4.4 of draft-ietf-rtcweb-security-arch essentially says that implementations MUST use the mechanism specified in draft-ietf-stun-consent-freshness. Section 5.3 of draft-ietf-rtcweb-security-arch establishes the normative requirement that ICE be used and how it be used and explains the need for consent freshness.

Section 8 says:

"Consent Verification to avoid attacks using a browser as
   an attack platform against machines is discussed in Sections 3.3 and
   4.2 of [I-D.ietf-rtcweb-security].”

Both of these references are about the need to obtain consent in the first place, and as such I think they are provided more to give the broader picture of where stun-consent-freshness fits into the RTCWEB security story. Section 3.3 explains the threat model that motivates the need to obtain communications consent. Section 4.2 explains how this threat is mitigated, namely by using ICE. 

The upshot of this is if the WG or the IETF decides before publishing the security documents that communications consent isn’t actually necessary (seems highly unlikely to me), then maintaining consent freshness won’t make much sense, but having published this draft wouldn’t be particularly harmful either since it will basically be meaningless. Likewise, I guess in theory consensus could emerge not to use ICE. But in either of those cases, we could obsolete draft-ietf-stun-consent-freshness if it had already been published. Furthermore, if consensus does emerge not to use ICE, there will probably be bigger problems with the RTCWEB document suite than the fact that draft-ietf-stun-consent-freshness was published.

If your concern is that the specific section numbers in the security documents might change, I think those could be taken out without issue.

Alissa


> I do not think
> it would be acceptable for a comment/discuss on the
> security documents to be received with "yes, but you
> approved consent-freshness and so we implemented and
> deployed that so you're too late to make that
> comment/discuss and expect some change."
> 
> 
> ----------------------------------------------------------------------
> 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?
> 
>