Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Dear Tramsters,

On Tue, Apr 21, 2015 at 10:36 AM, Stephen Farrell <[e-mail]
> wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-tram-stun-origin-05: Discuss


I saw an excellent exchange with Barry on his Discuss for this draft, but
haven't seen a response to Stephen's yet. Did I miss it?

If the answer is "as Stephen said, it IS a high-level Discuss, and we need
to confer before responding", that's fine, or really any other answer could
be fine - I just didn't want the draft to get stalled ...

Thanks!

Spencer


> 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> "Analytics" here together with the MUST include
> statements could amount to a fancy way to
> describe monetizing people's WebRTC calls in ways
> that the end user will just not expect. I'd like
> to check that we're not doing that, as it'd
> arguably run counter to e.g. RFC7258 or to the
> general trend towards data minimisation. And
> making privacy worse, even by a little, seems
> worse than making it better. (Note: I am here
> asking about the STUN/TURN server being perhaps
> unnecessarily told the origin, not the risk that
> someone sees that in-transit, which is handled in
> the draft already.)
>
> I do agree that the TURN 401-like challenge
> use-case is perhaps needed, but I do not see that
> other use cases need to see the origin for them
> to work at all.  And I'm not sure that such a
> spoofable origin is so useful for that TURN case,
> esp. when there's parallel work on an
> authenticated equivalent. (I mean the tram 3rd
> party thing.) I also don't see that that is
> needed for network management reasons - surely
> everything needed for network managment is no
> more nor less visible to the STUN or TURN servers
> when this is used vs. when this is not used.
>
> So why are we pushing for this?  If it is really
> only for so-called "analytics" then is that ok?
> (And where can I find a definition of what that
> means?)
>
> Apologies if this discuss seems somewhat high
> level, but as well as the general concern, the
> last paragraph of the current tram charter seems
> to me to me to say that tram ought not make
> privacy worse. But maybe I'm missing the
> networking function that needs this - if so, I'm
> sure someone will point that out.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>
> - intro, para 2: STUN only defines two auth modes
> that I can see, and you only mention two here -
> what's the 3rd one you mean? (Is it DTLS?)
>
> - What if >1 TURN session with different origins
> is being setup from same client/browser? Does
> that work? (Say two parallel calls, not the case
> where the same resource is being accessed at the
> same time loaded from different referring web
> pages.)
>
> - I'd suggest to not allow >1 ORIGIN in a STUN
> request? But that discussion seems to be in-hand.
>
> - section 2: suggest providng similar examples
> for all schemes, http(s),sip & xmpp.
>
> - 2.1 & 2.2: MUST include web origin - couldn't
> there be "private browsing" scenarios where that
> MUST would be a problem? I'm not suggesting that
> the origin exposes very much but I think a SHOULD
> would be more appropriate.
>
> - 2.1 last para: source here means the webrtc
> server right? That's a bit ambiguous and would be
> better clarified.
>
> - What is the benefit of sending an empty origin
> as opposed to no origin attribute? I don't see
> any and the former just advertises that the
> client is "privacy sensitive" which seems
> incongruous.
>
>
>