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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 20 Apr 2015 19:29:22 -0700

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

Is the normative language in section 2.1 intended to  mean that all stun
implementations used by a browser, SIP, or XMPP MUST/SHOULD comply with
this draft? If so, then this draft should probably update STUN. (This
might also be the case for section 2.2 and TURN).

If on the other hand, these sections are intended to apply only to
implementations that understand STUN Origin, then I agree no update is
needed,  but it might help to make that unambiguous in the text.
(Normally I think this sort of thing goes without saying, but I am not
sure of the intent in this case.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with all 3 points of Barry's discuss.

Does Spencer's comment about removing the mention of UDP fragmentation
mean people don't think this will be a problem?

In section 4, paragraph 4, can the STUN client reasonably expected to
know when privacy is paramount? I am a bit surprised not to find a
stronger statement about needing DTLS or TLS for  HTTPS origins.

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

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Apr 2015 06:08:41 -0500

Hi Ben,

See my response below.

- Alan -

> http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/

We meant the latter, that the normative language in this document applies
to implementations of this specification.  Right now there is a STUNbis
draft in TRAM, so if we want the latter, then we could normatively
reference it there.

OK, let us know if the discussion in the other thread is heading in the
right direction.

> mean people don't think this will be a problem?

We originally thought that there might be a real UDP fragmentation issue
back when we thought there were:

1. Valid use cases for multiple Origins, and
2. Multiple ORIGINs if included would be processed.

However, since then, we have ruled out multiple Origins for HTTP, SIP, and
XMPP.  And, we have realized that unless we change core STUN behavior,
multiple ORIGIN attributes wouldn't even be processed.

So, there is a highly theoretical problem that we can't rule out, but we
have considered it and discussed it in Dallas.  The consensus was not to
address it.

> stronger statement about needing DTLS or TLS for  HTTPS origins.

Even an HTTPS request will still, in general, send DNS queries in the
clear, and that is effectively what is going on here with STUN Origin.  If
there was no real penalty for DTLS or TLS, then we might put in a stronger
statement, but remember STUN and TURN are used to create candidates for
ICE, so the transport used becomes the transport for the resulting media
flow.  Running TURN over DTLS results in SRTP over DTLS which is double
encryption on the leg between the client and the TURN server.

> I agree with Barry that the first reference to STUN should probably go in

Yes, we'll fix that.

> entries 5 or 6 in Section 4")
You are correct.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Apr 2015 09:57:46 -0400

Le 2015-04-21 07:08, Alan Johnston a écrit :
> However, since then, we have ruled out multiple Origins for HTTP, SIP,
> and XMPP.  And, we have realized that unless we change core STUN
> behavior, multiple ORIGIN attributes wouldn't even be processed.
> 

In addition, fragmentation issues are being discussed more generally as
part of the STUNbis effort. Any new mechanism we end up inventing there
would implicitly be applicable to packets containing the ORIGIN attribute.

Simon

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Apr 2015 09:11:57 -0500

Ben,

Thanks for your quick response.  See a few comments below.

- Alan-

On Tue, Apr 21, 2015 at 9:00 AM, Ben Campbell <[email-masked]> wrote:

> Hi Alan, please see response to your responses, below.
>
> On 21 Apr 2015, at 6:08, Alan Johnston wrote:
>
>  Hi Ben,
>>
>> See my response below.
>>
>> - Alan -
>>
> [...]
>> to implementations of this specification.
>>
>
> Okay, I will clear the discuss, and add a (non-binding, of course) comment
> that I think the language could be read either way.
>
>
If we changed the first of these MUST statements to this, would it be more
clear:

"STUN clients compliant with this specification sending STUN requests sent
without authentication to a STUN server (i.e.STUN binding requests sent to
a STUN server) MUST include the ORIGIN attribute."

I removed the web origin part, as we plan to drop this distinction.

Or do you think every MUST should have this qualifier?

>  Right now there is a STUNbis
> I assume you meant "former"?
>

Oops - yes.

> Okay, that sounds perfectly reasonable.
>
>
> I can live with that if the security guys can :-)
>
> [...]
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Apr 2015 09:00:03 -0500

[...]

> to implementations of this specification.

Okay, I will clear the discuss, and add a (non-binding, of course) 
comment that I think the language could be read either way.

> and

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Apr 2015 09:27:37 -0500

[...]
>> comment

No, that way lies madness :-) 2.1 (and to a lesser degree 2.2) were the 
only parts that stood out in my mind as readable to mean "... MUST 
implement this spec"

>>> OK, let us know if the discussion in the other thread is heading in 

I see that Barry agreed to clear, and I'm okay with the discussion.

[...]