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

From: "Barry Leiba" <[email-masked]>
Date: Mon, 20 Apr 2015 13:47:34 -0700

Barry Leiba 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:
----------------------------------------------------------------------

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

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 20 Apr 2015 14:33:59 -0700

> draft-ietf-tram-stun-origin-05: Discuss

That rule just defines the Web browser compliant implementation.

> How does that help interoperability or security or whatnot?

There may be two reasons:

1) obtaining an empty ORIGIN, the server may know that the client is
ORIGIN-compliant, but it has no ORIGIN defined.
2) Empty ORIGIN may signal to the server that a "default" domain
(whatever it is) has to be used.

> yes to HTTP?

TURN server is not performing deep inspections of the traffic and it
has no means to learn that the traffic is related to SIP, XMPP, WebRTC
or anything else. So the rules must be universal.

>  If this really does apply to all cases, why are multiple

That section just explains what happens if the server got a request
with multiple ORIGIN attributes. It is not forbidden, and it is not
recommended. Those are just the rules that define the server's
behavior.

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Apr 2015 17:52:44 -0400

Ho, Oleg.  Thanks for responding.

> That rule just defines the Web browser compliant implementation.

I don't understand what that means.

> (whatever it is) has to be used.

That explains why you might or might not want to do one thing or the
other.  It doesn't answer why you have MUST or SHOULD there.

>> even though this says you SHOULD NOT?  (Why is it not "MUST NOT"?)

I didn't see a response to this.

> or anything else. So the rules must be universal.

In other words, your answer is "Yes, for all cases," right?

> recommended. Those are just the rules that define the server's

Again, you haven't answered the question I asked, then.  You're
defining a new protocol here.  Why are you allowing a feature and then
saying that it SHOULD NOT be used?

Barry

---

From: Alan Johnston <[email-masked]>
Date: Mon, 20 Apr 2015 21:04:39 -0500

Hi Barry,

See below for my response to your DISCUSS.  I'll respond to your COMMENTs
in another thread.

- Alan -

> other.  It doesn't answer why you have MUST or SHOULD there.

You are correct.  The thinking was that we could put a MUST requirement on
browsers (a limited set of implementations currently making lots of changes
in order to implement WebRTC).  For non-browsers, there is a huge number of
implementations that often are deployed in walled gardens, and some may not
have an origin - for this, we felt a SHOULD was more appropriate.

However, I don't have a good reason as to why a non-browser implementation
would support ORIGIN but not send it.

I'm fine with simplifying it to say that if an implementation is compliant
with this RFC, they always (MUST) send ORIGIN, but can send an empty one if
the info is not available (i.e. configured, since with HTTP there will
always be an origin, but with other uses, it might need to be manually
configured) or want to withhold it for privacy reasons.

> I didn't see a response to this.

In these cases, it just wastes bandwidth, but it doesn't do any harm.
However TURN SEND requests can be sent frequently (RTP media can be sent
over it), so putting it there would waste a lot of bandwidth.  Based on
that it could be that in a Send it would be MUST NOT (very wasteful of
bandwidth) but it isn't really a big deal on other non-Allocate requests.

> In other words, your answer is "Yes, for all cases," right?

Actually, we have since discovered that the STUN RFC 5389 says that if an
attribute appears multiple times, the first is processed and the others are
ignored.  So we can actually remove this text, since we aren't trying to
change STUN behavior.  Also, we haven't come up with any valid use cases
where multiple ORIGINs are generated and useful.

Our Gen-ART reviewer David Black also had issues with this text (
https://www.ietf.org/mail-archive/web/tram/current/msg01457.html) but due
to an error we haven't replied to him about it.

I think the best solution is to leave in this statement in section 2:

"Senders MAY include multiple ORIGIN attributes in a request, and receivers
MUST support parsing and receiving multiple ORIGIN attributes.  "

Since there is a theoretical chance of there being multiple ORIGINs.  But I
think we should delete this statement in section 2.7:

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

since it is not needed given STUN's default behavior.

---

From: Alan Johnston <[email-masked]>
Date: Mon, 20 Apr 2015 21:25:14 -0500

Barry,

Here's my reply on your COMMENTs (see the other thread for the DISCUSS).

- Alan -

> draft-ietf-tram-stun-origin-05: Discuss

Agreed - these are good points to fix.

> There is no Section 4.5 in RFC 7376.  Perhaps you mean Section 4, bullet

We mean Section 4, bullet 6, as this is the major use case for STUN ORIGIN:

" 6.  Hosting multiple realms on a single IP address is challenging
       with TURN.  When a TURN server needs to send the REALM attribute
       in response to an unauthenticated request, it has no useful
       information for determining which realm it should send in the
       response, except the source transport address of the TURN
       request.  Note that this is a problem with multi-tenant scenarios
       only; this may not be a problem when the TURN server is located
       in enterprise premises."

> you're trying to say here?

Yes, it really is true.  STUN binding requests to a STUN server are never
authenticated - it is more work to authenticate them than to just respond,
since it really is just a glorified Ping server.

> this, particularly because it's involved in a "MUST".

Sure, a web origin would always have an http/https origin, so we can phrase
it that way.

> the Security Considerations is enough to answer that question up here.

That is what is meant, so if you think stating that makes it more clear,
then we can do so.

> third sentences.  Apart from that, I have the same comments here that I

OK, as I said in the DISCUSS thread, I'm fine with simplifying the behavior
so that all usages MUST include ORIGIN.

> qualifier and merging the "TLS/DTLS SHOULD be used" advice from the two

The scenario is an eavesdropper who can learn the web sites visited from
the ORIGIN attribute in an unencrypted STUN message.  This is basically the
same information in a DNS query, which is also currently unencrypted.  If
some form of confidentiality is being used for DNS, then it should also be
used for STUN.

But I'm fine with dropping this qualifier and just saying SHOULD.

> rely on information from the ORIGIN attribute in the absence of secure

That seems reasonable.

> saying the same thing twice saying the same thing twice.
Are you saying that we should start new paragraphs at the "In cases
where..."?  These statements are the summation of the discussion earlier in
the paragraphs, so putting them in a separate paragraph seems to me will
leave the earlier paragraphs lacking.  But maybe others have a good way of
phrasing this.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Apr 2015 23:08:37 -0400

Hi, Alan.  Thanks for your response.  It fully resolves my DISCUSS; see below.

> The thinking was that we could put a MUST requirement on

That'd be a good solution; thanks.  The key points to me are (1) being
consistent about sending empty ORIGIN or none at all, and (2)
explaining when it's appropriate to do that.  What you have above
covers both.

> over it), so putting it there would waste a lot of bandwidth.  Based on that
> it could be that in a Send it would be MUST NOT (very wasteful of bandwidth)
> but it isn't really a big deal on other non-Allocate requests.

OK.  I prefer having it be MUST NOT for all cases where it's not
appropriate, but do what you see best.  What I need for the DISCUSS is
the explanation -- that it is not used in those cases and wastes
bandwidth.  Thanks.

>> SIP and XMPP?  Or SIP, XMPP, and WebRTC?  But not to other HTTP uses?
>> Or yes to HTTP?
>
> Our Gen-ART reviewer David Black also had issues with this text
> (https://www.ietf.org/mail-archive/web/tram/current/msg01457.html) but due

OK.

If you don't think there are valid cases to use multiple ORIGINs, I
think it's best not to allow them, or at least to discourage them.
Perhaps best would be to say "SHOULD NOT include multiple ORIGIN
attributes", rather than "MAY", with an explanation that it's
theoretically a reasonable situation, but there are no actual valid
cases (but still leave the "MUST support" on the receiving side, in
case valid cases arise later).

But that's my preference, not a requirement.  I'm already OK with
clearing the DISCUSS based on the explanation and the removal of the
confusing sentence.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Apr 2015 23:21:33 -0400

> Here's my reply on your COMMENTs (see the other thread for the DISCUSS).

And thanks for considering my comments (and accepting most of them).
I'll leave the edits to you.  Below is just a response on the point
where you weren't sure what I was suggesting.

> leave the earlier paragraphs lacking.  But maybe others have a good way of

Sorry for not being clear.  Here's what I meant, specifically (and
it's purely a suggestion, so do as you think reads best):

OLD
   The STUN ORIGIN attribute has privacy implications.  As a result, TLS
   or DTLS transport SHOULD be used.  If STUN requests containing the
   origin attribute are not encrypted with TLS or DTLS, an on-path
   attacker could determine this information by inspecting STUN messages
   between the STUN client and STUN server.  This information is often
   available in other messages sent by the browser, such as DNS or HTTP
   requests.  However, in cases where secure HTTP is used, including the
   ORIGIN attribute over an unencrypted transport could leak this
   information.  In cases where privacy is paramount, but TLS or DTLS
   transport is not available, the ORIGIN attribute MAY be sent with an
   empty (null) origin value.  It is up to the server what to do when
   receiving such an empty origin.  The server could fail the request,
   or the server could assume an origin and attempt to process the
   request.

   The STUN ORIGIN attribute also has privacy implications in that the
   origin information is shared with a STUN or TURN server which
   otherwise might not know this information.  This information could be
   used to track usage of real-time communication services.  A STUN or
   TURN server will always know the public IP address of each user, but
   the ORIGIN attribute provides more information about which service or
   provider is being used.  The particular STUN and TURN servers used
   are usually selected by the real-time communications service provider
   (i.e. the web provider for WebRTC or the SIP or XMPP service
   provider).  In addition, they are usually also run by the same
   provider, or by a trusted partner, especially for TURN.  However, a
   service or provider using an untrusted third party STUN or TURN
   server needs to recognize that the operator of the third party STUN
   or TURN server will learn the identity of the service or provider
   through this extension.  In cases where the STUN or TURN client does
   not wish to share origin information with the server for privacy
   reasons, the ORIGIN attribute MAY be sent with an empty (null) origin
   value.  It is up to the server what to do when receiving such an
   empty origin.  The server could fail the request, or the server could
   assume an origin and attempt to process the request.

NEW
   The STUN ORIGIN attribute has privacy implications.  As a result, TLS
   or DTLS transport SHOULD be used.  If STUN requests containing the
   origin attribute are not encrypted with TLS or DTLS, an on-path
   attacker could determine this information by inspecting STUN messages
   between the STUN client and STUN server.  This information is often
   available in other messages sent by the browser, such as DNS or HTTP
   requests.  However, in cases where secure HTTP is used, including the
   ORIGIN attribute over an unencrypted transport could leak this
   information.

   The STUN ORIGIN attribute also has privacy implications in that the
   origin information is shared with a STUN or TURN server which
   otherwise might not know this information.  This information could be
   used to track usage of real-time communication services.  A STUN or
   TURN server will always know the public IP address of each user, but
   the ORIGIN attribute provides more information about which service or
   provider is being used.  The particular STUN and TURN servers used
   are usually selected by the real-time communications service provider
   (i.e. the web provider for WebRTC or the SIP or XMPP service
   provider).  In addition, they are usually also run by the same
   provider, or by a trusted partner, especially for TURN.  However, a
   service or provider using an untrusted third party STUN or TURN
   server needs to recognize that the operator of the third party STUN
   or TURN server will learn the identity of the service or provider
   through this extension.

   Because of these privacy implications, in cases where TLS or DTLS
   is not available or the client does not wish to share origin information
   with the server the ORIGIN attribute MAY be sent with an
   empty (null) origin value.  It is up to the server what to do when
   receiving such an empty origin.  The server could fail the request,
   or the server could assume an origin and attempt to process the
   request.

END

The changes are just to cut the last sentences of each paragraph and
to consolidate the cut part into the third paragraph.

Barry