Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN

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

On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
> 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?
> 

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: Keith Moore <[email-masked]>
Date: Sun, 30 Oct 2011 00:44:21 -0400

On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote:

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

Security schemes change over time as new (presumably better) ones appear, and vulnerabilities are discovered in old ones.   There's nothing inherently wrong with having a URI scheme end in "s".  But it's a Bad Idea to promote the notion that "s" means "security".

Keith

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 30 Oct 2011 11:34:31 -0400

> Security schemes change over time as new (presumably better) ones appear, and vulnerabilities are discovered in old ones.   There's nothing inherently wrong with having a URI scheme end in "s".  Bu…

I understand the "s" suffix as meaning "the transport to the next app level hop
MUST be secure", which actually means TLS, but it could be anything else.  I
agree that it would have been a better idea to define a scheme separator like in
[1], to not have to register multiple schemes (i.e. "sip+s:", "http+s:",
"turn+s:", etc...).  Similarly, one can define a suffix (say +sec) that means
e2e security like in [2].  That would give "sip+sec:" for e2e SIP security, and
"turn+sec:" for a secure transport and allocation.

[1] http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
[2] http://tools.ietf.org/html/draft-gurbani-sip-sipsec

- -- 
Marc Petit-Huguenin

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Oct 2011 12:02:13 -0400

On Oct 30, 2011, at 11:34 AM, Marc Petit-Huguenin wrote:

> MUST be secure", which actually means TLS, but it could be anything else.

The fact that people "understand" this is a good reason to stop using this convention.

All of the examples of the "s" suffix that I'm aware of originally used SSL.   "https" could be understood as an abbreviation for "HTTP over SSL".

Keith

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 30 Oct 2011 09:04:15 -0700

> MUST be secure", which actually means TLS, but it could be anything else.
err..... TLS with a NULL cipher and no certification checking is NOT secure.
Neither is TLS with 40-bit RC4, although it takes a little effort to 
break (CPU-minutes).
>    I
If we need to indicate security functionality requirements in the URL (a 
doubtful proposition), I think the better solution is

<scheme>:<stuff>;auth=cert;crypt=tls

or someting like that (with suitable profiling for those values)

In TURN's case, we have exactly 3 currently defined operational modes, 
which require you to know which one to select before you start 
connecting, so

turn://user@host;mode=<udp, tcp or tls>

seems like a reasonable thing to do.

Reading security as a binary "either it's secure or it's not" is usually 
not a sign that the requirements for the situation have been deeply 
analyzed.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6tboMACgkQ9RoMZyVa61eTTACgoDKJ5LQ1KFwFH1Epnc2x/iH4
> x90AoJ+ogURbCcw682se9lj+luF1gQgs
> =MfbQ
> -----END PGP SIGNATURE-----
>

---

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

> indicate security is a bad thing.
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.

> iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E
> aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl
> =yx3i

---

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:
> 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: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 20:09:56 +0100

> "turn+sec:" for a secure transport and allocation.

Using "sips" in SIP has been a very bad idea, not just because the
spec is unfeasible (yes, there are bugs and things that are impossible
to achieve) bu also because SIP defines URI for users, not just for
servers (as HTTP does). So when you (sip:[email-masked]) receive a
call from "sips:[email-masked]", must you consider he is the same as
"sip:[email-masked]"? What about if you set presence watching
permissions (via XCAP) to "sip:[email-masked]" but receive a presence
request from "sips:[email-masked]"? is it the msae? These are open
questions with hard response. Nowadays NOBODY use "sips" schema, so
adding more schemas (as "sip+sec") is still a vworse idea.

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

---

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
> 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: Keith Moore <[email-masked]>
Date: Mon, 31 Oct 2011 11:33:33 -0400

> defined scheme by scheme)?

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. 

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 don't want that to depend on the URI scheme.  

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

Keith

---

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
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb