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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 21 Apr 2015 08:36:35 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tram-stun-origin-05: 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 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.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2015 11:41:45 -0400

> would be more appropriate.

The discussion of my DISCUSS (about making the advice consistent for
all schemes) came down to whether it should be SHOULD include on
all... or MUST include on all, but it MAY be empty.  I think the
authors plan to make it the latter.  The "MAY be empty" part should
take care of your concern here.  In a private browsing scenario, the
browser would send an empty origin, and the "client doesn't want to
share the origin info with the server" issue is discussed in the last
paragraph of the Security Considerations.

b

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Apr 2015 16:43:26 +0100

> paragraph of the Security Considerations.

That may be the answer, but see my last comment:-) Given that
I'd assume STUN/TURN servers will have to live with browsers
or other client that never send an origin, I don't see why one
would ever want to send an origin with no value.

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Apr 2015 08:32:45 -0500

Dear Tramsters,

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Apr 2015 14:35:56 +0100

On 23/04/15 14:32, Spencer Dawkins at IETF wrote:
>> draft-ietf-tram-stun-origin-05: Discussn 
> 
> 

And I'd also like to chat about it today if possible - I think
this is one where getting a sense of the IESG's location on the
[crazy-farell,it-needed-to-be-said] spectrum would be good I
think. So I hope we don't skip over talking about this for the
lack of an author/WG response too.

S.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 23 Apr 2015 08:42:51 -0500

Hi Stephen & Spencer,

The authors and implementors of STUN Origin have been discussing it - we'll
send our reply later today to the list.

- Alan -

On Thu, Apr 23, 2015 at 8:35 AM, Stephen Farrell <[email-masked]>
wrote:

> >> Please refer to
> http://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Apr 2015 09:18:50 -0500

Hi, Alan,

Thanks for the update.

The IESG would like to talk about this on the next telechat ("deserves
voice discussion"), which is 5-14.

Telechats are now open to anyone as observer (details for today's call at
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg14032.html
would be the same for the 5-14 call), and if Simon would like to be on the
call to answer questions, shepherds are always invited to do that ...

And thanks to you all for addressing Barry's Discuss quickly.

Spencer

On Thu, Apr 23, 2015 at 8:42 AM, Alan Johnston <[email-masked]>
wrote:

> Hi Stephen & Spencer,
>
> The authors and implementors of STUN Origin have been discussing it -
> we'll send our reply later today to the list.
>
> - Alan -
>
> On Thu, Apr 23, 2015 at 8:35 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>>