An Origin Attribute for the STUN Protocol
Summary: Has a DISCUSS. Needs 2 more YES or NO OBJECTION positions to pass.
Alissa Cooper Discuss
Discuss (2015-05-11 for -05)
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.
(Stephen Farrell) Discuss
Discuss (2015-04-21 for -05)
"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 (2015-04-21 for -05)
- 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.
(Barry Leiba) Discuss
Discuss (2015-04-20 for -05)
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?
Comment (2015-04-20 for -05)
-- Section 1 -- A minor thing: the citation for STUN in the first two sentences seems odd. Instead of citing 5389 with the first use of "STUN" in the first sentence, you cite it in the second sentence where it appears to be a reference for "a STUN extension". I suggest moving the citation to the first sentence, so: "STUN, or Session Traversal Utilities for NAT [RFC5389], is a protocol used...." It wouldn't be a bad thing to add an informative reference to CORS and to cite it when you mention it. <http://www.w3.org/TR/cors/> There is no Section 4.5 in RFC 7376. Perhaps you mean Section 4, bullet 5? -- Section 2.1 -- For STUN requests sent without authentication to a STUN server (i.e. STUN binding requests sent to a STUN server), the STUN client MUST include the ORIGIN attribute when the origin is a web origin. For other origins, such as SIP or XMPP, the STUN client SHOULD include the ORIGIN attribute. Note that for privacy reasons, an empty ORIGIN attribute can be sent, as described in the Security Considerations. The "i.e." tells me that the two things are synonymous: that "STUN requests sent without authentication" is the same as "STUN binding requests". Is that really true? Is it true that all binding requests are sent without authentication? Or am I quite misunderstanding what you're trying to say here? What, exactly, do you mean by "when the origin is a web origin"? From the previous section, that seems to refer to something sent by a web browser. But a web browser is just a piece of software, and a web browser could happen to be a SIP or XMPP client, as well. Do you really mean to refer to origins that use the "http" scheme? You might clarify this, particularly because it's involved in a "MUST". A STUN server can derive additional information for logging and analytics about the request through the ORIGIN attribute, such as the source of the request. For example, an enterprise STUN server might only reply to STUN binding requests from certain domains. In the example case, does that mean that such a server would not reply to binding requests that lacked ORIGIN (or had an empty one)? If so, that would be a good bit of explanation to add. I don't think that what's in the Security Considerations is enough to answer that question up here. -- Section 2.2 -- When the origin is a web origin, TURN [RFC5766] Allocate requests MUST include the ORIGIN attribute. For all other TURN requests, including the Send method, the use of the ORIGIN attribute is NOT RECOMMENDED. For other origins, such as SIP or XMPP, TURN Allocate requests SHOULD include the ORIGIN attribute. The order here is odd, and made me read it a few times to be sure that I (thought I) understood it. I would switch the order of the second and third sentences. Apart from that, I have the same comments here that I had about Section 2.1. -- Section 4 -- DTLS or TLS transport SHOULD be used when integrity protection for the ORIGIN attribute is important. Just curious here: When is integrity protection for it *not* important (and how will the client know that), given that the server might use it to determine whether it should respond, or to affect the authentication challenge? (And, actually, the first sentence of the next paragraph repeats the SHOULD without the qualifier. I suggest just removing the qualifier and merging the "TLS/DTLS SHOULD be used" advice from the two paragraphs. Also, given that Section 2.1 says that the server might use it for logging and analytics, it might be good to add that the server SHOULD NOT rely on information from the ORIGIN attribute in the absence of secure transport. I suggest factoring out the ends of the last two paragraphs (the parts that start with "In cases where") into a new last paragraph, rather than saying the same thing twice saying the same thing twice.
Spencer Dawkins Yes
Comment (2015-04-20 for -05)
Just to keep the IESG in the loop, without revising the document during balloting ... In discussion in Dallas, the editor agreed to remove this sentence from Section 2. of draft-ietf-stun-origin: "The size of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation." This mention of fragmentation had raised the possibility of requiring support for SCTP in STUN and other things that there was no interest in doing, so the decision was to just remove this non-normative statement. Also, this statement is highly speculative as there are no known use cases where multiple ORIGINs will be included for WebRTC, SIP, or XMPP.
(Jari Arkko) No Objection
Comment (2015-05-13 for -05)
I assume that the changes agreed on a thread about David Black's Gen-ART review will be done in a subsequent revision of the draft. Thanks.
Alia Atlas No Objection
Deborah Brungard No Objection
Ben Campbell (was Discuss) No Objection
Comment (2015-05-14 for -05)
Edit: My comments have been addressed in discussion, with the expectation of some very minor edits. I agree with all 3 points of Barry's discuss. I think the normative language in section 2.1 is ambiguous about whether it applies to all stun implementations used by a browser, SIP, or XMPP, or just those that "implement this draft". A thoughtful reader can infer the answer from the fact that the draft does not update STUN, but it might be helpful to clarify. [Removed some comments that have been explained to my satisfaction] Nits: -- Section 1: I agree with Barry that the first reference to STUN should probably go in the previous sentence. Should reference to " Section 4.5 of [RFC7376]" really be 4.6"? 4.5 talks about a MiTM learning USERNAME. 4.6 talks about hosting multiple realms from the same IP address. (And as Barry mentioned, these are really "List entries 5 or 6 in Section 4")
Benoit Claise No Objection
Comment (2015-05-12 for -05)
Here is Tim Chown's OPS DIR review, along the same lines as Stephen and Alissa's DISCUSSES. The feedback was sent to the authors on April 22nd, and I have not seen any reply so far. Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I would summarise this document as being Not Ready. My concern with the draft lies with privacy aspects. While the area is not one that I am particularly familiar with, but there would seem to be additional potential exposure through this method, and the language of the draft seems at odds with the language in RFC6454 (Section 7.3). I would therefore urge the AD to review this aspect, and to determine whether the utility of the draft outweighs the privacy concerns, and if it does, that appropriate privacy ‘knobs’ are included for those who are ‘privacy-sensitive’ (in the language of RFC6454). I think the rationale and tradeoffs could be more clearly stated in the document. With recent passive pervasive monitoring threats, the IETF is now supposed to be considering whether given information *needs* to be transmitted in any given protocol. Would I as a user, for example, be able to toggle a setting that would mean my ORIGIN would always be “null”, as per RFC6454 section 7.3? Is the use of ORIGIN *required*, or is it just ‘desirable’? Would my application fail, or not? It appears from Section 1 that its inclusion is ‘useful’, but not required. Section 4 talks of TLS for avoiding eavesdropping of ORIGIN in STUN messages, but the privacy concern is not necessarily only with transmission of the information. I think here paragraph 3 of Section 4 is at odds with RFC6454 Section 7.3 - with this draft saying MAY wrt use of a “null” Origin, and RFC6454 saying MUST for use of “null”. The same applies to the end of the last paragraph in Section 4 as well. The draft should probably use the ‘privacy-senstive’ context terminology of RFC6454, as per Section 7.3, and describe how the user can influence the privacy settings where they which to maximise their privacy. Tim ===================================================== A point of detail, really, if you update the draft. For a web application provider STUN or TURN server, the server will have no idea which web pages or sites are sending binding requests to the service. In conventional applications, the SOFTWARE attribute would provide some identifying information to the service, but that no longer works when the browser is the application. SOFTWARE attribute: a reference to http://tools.ietf.org/html/rfc5389#section-15.10 would be beneficial
(Brian Haberman) No Objection
(Joel Jaeggli) No Objection
Terry Manderson No Objection
Kathleen Moriarty No Objection
Comment (2015-04-21 for -05)
I support Stephen's Discuss.