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

["Stephen Farrell" <[e-mail]>]

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

(5) Cleared.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


(Was discuss point#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."
Alissa gave me the reference [1] sothat's grand. It
might be an idea to make that clearer if it wasn't
just me missing it as I read, which is very possible;-)

[1] https://tools.ietf.org/html/rfc5389#section-6

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