Subject: [rtcweb] URI schemes for TURN and STUN

From: Harald Alvestrand <[email-masked]>
Date: Sat, 29 Oct 2011 14:11:16 -0700

Hi,
being in the process of scanning all the drafts with -rtcweb- in them, I 
came across these two:

draft-nandakumar-rtcweb-stun-uri-00.txt
draft-nandakumar-rtcweb-turn-uri-00.txt

Just three comments:

- I think it's not RTCWEB business. They should be pointed at the home 
group for STUN/ICE.
- I do not think it's appropriate to use "turn" and "turns" for 
indicating transport. Polluting the URI namespace with more 
configuration parameters in the form of trailing "s" is a Bad Thing.
- Passing passwords in URIs is generally a Bad Practice. If you really 
want this in this case, please explore the implications thereof fully in 
the Security Considerations section.

Good luck with the discussion (elsewhere)!

                  Harald

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 00:36:00 +0200

2011/10/29 Harald Alvestrand <[email-masked]>:
> - I do not think it's appropriate to use "turn" and "turns" for indicating
> transport. Polluting the URI namespace with more configuration parameters in
> the form of trailing "s" is a Bad Thing.

But there should be some way to indicate that a TURN server listens in
TLS, right?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 29 Oct 2011 16:23:12 -0700

> But there should be some way to indicate that a TURN server listens in

We should continue this discussion in BEHAVE, but I would like to ask the OP to
send a pointer on the RFC or discussion that says that using a trailing "s" to
indicate security is a bad thing.

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 01:26:25 +0200

2011/10/30 Marc Petit-Huguenin <[email-masked]>:
> I would like to ask the OP to

Well, in http (so https) it's a good idea.
In SIP (using "sips" instead of "sip" schema) it's a pain nobody wants
to deal with (and there are bugs in the specifications).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 29 Oct 2011 21:40:56 -0700

On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> 2011/10/29 Harald Alvestrand<[email-masked]>:
I'll have to forward this question to the apps ADs of a few years ago 
about whether there's documentation for it. It does not seem to have 
been captured in an RFC that I can find; discussion was in the 
~2000-2005 timeframe.

The short version, from memory: Doing "s" locks you into one and exactly 
one security scheme, and prevents you from saying anything about the 
requisite parameters for that scheme, while using AUTH parameters such 
as POP or in-band negotiation such as IMAP  are much more flexible 
approaches.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E
> aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl
> =yx3i
> -----END PGP SIGNATURE-----
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Oct 2011 07:28:56 -0700

On Sat, Oct 29, 2011 at 9:40 PM, Harald Alvestrand <[email-masked]> wrote:
>>>> indicating
> I'll have to forward this question to the apps ADs of a few years ago about
> whether there's documentation for it. It does not seem to have been captured
> in an RFC that I can find; discussion was in the ~2000-2005 timeframe.
>
> The short version, from memory: Doing "s" locks you into one and exactly one
> security scheme, and prevents you from saying anything about the requisite
> parameters for that scheme, while using AUTH parameters such as POP or
> in-band negotiation such as IMAP  are much more flexible approaches.

I haven't formed an opinion on the value of turn[s] URIs one way or
another, but...

What you say above is absolutely true, but there is a tradeoff here. If you just
provide a URI with no indication of the expected security mechanism, and
rely on in-band negotiation, then an active attacker can force the client down
to the weakest security mechanism (a downgrade attack). So, for instance,
if the client supports both TURN and TURN over TLS, the attacker can
impersonate a server which supports only TURN and force the client
to accept that. By contrast, if the URI indicates a minimal security
mechanism that is
sufficiently strong, then this form of attack is not possible. Obviously, the
user could configure his client to only support secure connections
(via whatever mechanism) but this is less convenient.

Another point in the design space is to require some specific security mechanism
that is strong enough to authenticate the server and then use that mechanism
to support secure negotiation of the real mechanism. Unfortunately, the only
widely supported mechanism that meets that standard is TLS, so this isn't
much of an improvement.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2011 17:05:52 -0700

On Oct 29, 2011, at 15:11 , Harald Alvestrand wrote:

> Hi,
> being in the process of scanning all the drafts with -rtcweb- in them, I came across these two:
> 
> - I think it's not RTCWEB business. They should be pointed at the home group for STUN/ICE.

I suspect the point of putting rtcweb in the name was so this group of people would find them. I doubt you would have noticed them had they been named behave. That said, I did ask the authors to send emails about them to the behave WG. So I get your point,  but I think they were meant for this group to read. I know I would not have noticed them had they been in behave. 

> - I do not think it's appropriate to use "turn" and "turns" for indicating transport. Polluting the URI namespace with more configuration parameters in the form of trailing "s" is a Bad Thing.

It's a bit more complicated than that - some time this is the right thing, sometimes not. I have no idea of the case here but just saying HTTPS was a Bad Thing seems a bit over simplistic. Anyways - I'd have to think about what we need to accomplish, what the use cases are and try to sort this out. I'm not arguing for or against turns - I'd want to see a bit more info before getting into that. 

> - Passing passwords in URIs is generally a Bad Practice. If you really want this in this case, please explore the implications thereof fully in the Security Considerations section.

Agree it is not good. Questions is, is it any worse than passing them JS downloaded over HTTP or HTTPS? I note that is is what another document I am co-author of is suggesting so I'm a bit sensitive about how that conversation goes. I don't have real strong feeling about if it should be in the TURN URI or not but I have pretty strong feelings that it is either going to be in the URI or sitting in the same HTTP doc right beside the URI with all the same "Bad Practice" issues either way. 

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 31 Oct 2011 12:26:55 +0900

For the http vs. https case, there is a very good answer from Roy 
Fielding at
http://lists.w3.org/Archives/Public/www-tag/2006Mar/0040.html

In essence, not distinguishing the two schemes would mean either 
additional roundtrips (assuming http is the more frequent one) or 
exposition of data on the network that was supposed to be private.

Regards,    Martin.

On 2011/10/30 13:40, Harald Alvestrand wrote:
>> - -- Marc Petit-Huguenin

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 31 Oct 2011 12:30:04 +0900

> - I think it's not RTCWEB business. They should be pointed at the home

For TURN, there's already
http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-04.

Regards,    Martin.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 30 Oct 2011 22:26:30 -0700

[BA] Agree with Harald here.   These items are (at best) tangential and better handled (or discarded) elsewhere.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 31 Oct 2011 07:57:47 -0700

Hi Martin,

So I understand Roy's email as saying in fact the opposite of what Harald said,
i.e. that using an "s" suffix to signify security is a good thing.

What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec")
that would indicate a well defined set of security properties that could apply
to any scheme, (vs the current "s" suffix where security properties has to be
defined scheme by scheme)?

Also, what would be the best place to discuss this?

Thanks.

On 10/30/2011 08:26 PM, "Martin J. Dürst" wrote:
> For the http vs. https case, there is a very good answer from Roy Fielding at
> In essence, not distinguishing the two schemes would mean either additional
> roundtrips (assuming http is the more frequent one) or exposition of data on the
> network that was supposed to be private.
> 
> Regards,    Martin.
> 

- -- 
Marc Petit-Huguenin

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 01 Nov 2011 15:37:05 +0900

On 2011/11/01 0:33, Keith Moore wrote:
>
> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote:
>
> There is no "well defined set of security properties that could apply to any scheme".   Security properties necessarily vary depending on the way a resource is used, the threat model, and so forth.

Here I agree with Keith.

> Also, the idea that there should be a "secure" bit in a URI scheme, to distinguish it from the "insecure" form of a URL, doesn't make much sense.  You always want to use the best security that's available.

You always want the best security you're willing to pay for.

> You don't want that to depend on the URI scheme.

Ideally not, but in actual operation, it made a lot of sense for HTTP as 
Roy has explained.

> The "s" convention was a hack to distinguish "x over SSL" from "x" for all of the URIs that existed before SSL was well-established, because those protocols didn't (then) have a way to negotiate security in-band.   It made sense as a short term hack,

Yes. It also makes sense in current-day operation.

> but not as an architectural feature.   It's not something that we want to propagate to new URI types, neither in the form of an "s" suffix, nor as any other syntactic convention.

In most cases probably not. But there may be cases similar to HTTP/S 
where it makes sense. Each case has to be analyzed independently.

Regards,    Martin.

> Keith