An Origin Attribute for the STUN Protocol
draft-ietf-tram-stun-origin-06

This is a bit of a weird DISCUSS since I didn't manage to ballot when the document was first on the IESG's agenda, so I'm coming in mid-stream.

I support Stephen's DISCUSS. If Alan's proposed changes make it into the document, they would resolve most of my concerns. However, I still see a problem with this proposed new text:

"For STUN requests sent without authentication to a STUN server (i.e.

   STUN binding requests sent to a STUN server), the STUN client SHOULD 

   include the ORIGIN attribute.  The ORIGIN attribute MUST NOT be included 

   if it is a "privacy-sensitive" context, as discussed in the Security Considerations

   section."

For requests sent with authentication, I understand that the origin attribute needs to be accurate in order for the client to authenticate. In those cases, the STUN server can rely on the attribute it receives. But for requests without authentication, what prevents the client from lying? And if those requests are not (D)TLS-protected, what prevents them from being modified in transit? I understand Alan to be saying that the justification for the origin in this case is operational troubleshooting, but if the server can't rely on the origin it receives, doesn't that make it risky for the server to act on that information?

My additional concern is about the use of "logging" as a justification for including and origin attribute. Logging in and of itself is not a reasonable justification. Alan's mail discussed the use of the origin for operational troubleshooting, which seems like what might actually be intended instead of "logging." In any event the purpose for the logging either needs to be explained or "logging" should not be listed as a justification.

I have three questions I'd like to discuss.  The discussion might or might not lead to any document changes, so let's please have the discussion first, and see where it leads.

1. In Sections 2.1 and 2.2, I find this combination odd:

a. For non-web origins, you SHOULD (not MUST) send ORIGIN.
b. But for web origins, you MUST send ORIGIN.
c. But that ORIGIN can be empty.

If you're allowed to send an empty origin, and you can sometimes not send ORIGIN at all, why is ORIGIN REQUIRED (but can be empty) in some cases?  How does that help interoperability or security or whatnot?

2. In Sections 2.2 and 2.6, about the SHOULD NOT ("NOT RECOMMENDED"): Why?  What happens if you use it?  Under what conditions might you do so, even though this says you SHOULD NOT?  (Why is it not "MUST NOT"?)

3. In Section 2.7:

   Therefore, if
   a STUN request contains multiple origins, the first origin MUST be
   used and the remaining origins ignored.

For all cases (that's what it says)?  Or was this just meant to apply to SIP and XMPP?  Or SIP, XMPP, and WebRTC?  But not to other HTTP uses?  Or yes to HTTP?  If this really does apply to all cases, why are multiple origins allowed in the first place?

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