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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Nov 2011 14:24:05 +0100

On 2011-10-31 04:30, "Martin J. Dürst" wrote:
> On 2011/10/30 6:11, Harald Alvestrand wrote:
>> 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.

Well, I think this boils down to an RTCWEB WG requirement to the W3C
saying something like:

The API must enable the application to configure the WebRTC stack with
one or more STUN or TURN resources. This configuration will need to
include security credentials for using those resources.

>From my perspective I think it is W3C that needs to consider if they
want to use an URI format, or have tuple providing host name/address,
transport, security, and security credentials.

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

I also think the draft authors should take RFC 5928 into account here.
That document defines how DNS can be used to resolve TURN resources
using S-NAPTR.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 01 Nov 2011 13:50:24 -0700

On 11/01/2011 01:44 PM, Harald Alvestrand wrote:
> Top-posting a general principle, detailed comment at the bottom....
> 
> For all URI schemes, I think the URI needs to contain all the information you
> need in order to make contact with the service; you can't negotiate until you've
> made contact.
> (the process may involve things like "resolve through a resolution mechanism
> like DNS" or "get authorization tokens from somewhere else").
> 
> In the case of TURN, you need to distinguish between TCP, UDP and TLS, and you
> need to make that determination before you send the first packet. That means the
> distinguishing information between those three things belongs in the URL; I
> don't think the scheme is a good place to encode it.
> 
> On 10/31/2011 11:37 PM, "Martin J. Dürst" wrote:
>>
>>
>> On 2011/11/01 0:33, Keith Moore wrote:
>>>
>>> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> 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)?
>>>
>>>
>>> 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.
> I think it made a lot of sense because the port 443 convention meant that you
> had to know whether or not to use SSL had to be known before you sent the SYN
> packet.
> 

Well, same thing for TURN, as a different default port is used when TLS is used
(3478 for TURN over UDP and TCP, and 5349 for TURN over TLS).

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 01 Nov 2011 13:44:19 -0700

For all URI schemes, I think the URI needs to contain all the 
information you need in order to make contact with the service; you 
can't negotiate until you've made contact.
(the process may involve things like "resolve through a resolution 
mechanism like DNS" or "get authorization tokens from somewhere else").

In the case of TURN, you need to distinguish between TCP, UDP and TLS, 
and you need to make that determination before you send the first 
packet. That means the distinguishing information between those three 
things belongs in the URL; I don't think the scheme is a good place to 
encode it.

On 10/31/2011 11:37 PM, "Martin J. Dürst" 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.
>
> Ideally not, but in actual operation, it made a lot of sense for HTTP 
> as Roy has explained.
I think it made a lot of sense because the port 443 convention meant 
that you had to know whether or not to use SSL had to be known before 
you sent the SYN packet.

---

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:
>> 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.
> 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: 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: Keith Moore <[email-masked]>
Date: Tue, 1 Nov 2011 08:05:28 -0400

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

agree.  I just don't think it's a good idea to establish a new _convention_.

regards,

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Nov 2011 11:58:57 -0700

> agree.  I just don't think it's a good idea to establish a new _convention_.

i don't really understand what you're arguing here.

The relevant issue is that we want to have a reference that Bob can provide
to Alice that guarantees that when it's dereferenced it provides a minimum
set of security properties.

Let's imagine some hypothetical new protocol which is like HTTP but not HTTP,
say HTTQ. It runs over TCP so you can use it directly or over TLS (i.e.,
HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it,
httq://.../. How do you propose to provide the above security property?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Nov 2011 11:54:13 -0700

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

What the "s" means is "Connect via TLS and check the server cert".
People are free to infer
whatever they want about the level of "security" provided.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Nov 2011 12:43:10 -0700

On Thu, Nov 3, 2011 at 12:29 PM, Keith Moore <[email-masked]> wrote:
>
> On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote:
>
> If you're going to define a new protocol, it should always use TLS (or it should always provide a minimum set of security properties).  Then you define a single URI type for the new protocol, and it doesn't need the security flag.

OK. I agree with this.

> It's only when you're trying to retro-fit security into an existing protocol that is already widely used, doesn't inherently provide a reasonable level of security for that application, and the security isn't securely negotiated in-band, that you need a security flag in the URI.

Sure.

> More generally, the right place to set the minimum security level is in the application, not in the name of the resource.  The reason you need https vs. http is that the two are really different protocols, and the client has to know a priori whether to send "GET..." or to negotiate the TLS layer after the TCP open completes.

I don't agree with this, however. The reason you need https: versus
http: is that it's the server providing the reference and it's the
only one that knows whether the resource is to be accessed over TLS or
not.

As a point of historical trivia, the initial use of this general
convention wasn't https:// but rather shttp://, and the intent of the
originator, Allan Schiffman, was to make it impossible for a
non-Secure HTTP capable client to accidentally reference via HTTP a
resource which should be secure.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Nov 2011 15:29:26 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Nov 2011 16:04:17 -0400

> only one that knows whether the resource is to be accessed over TLS or

Right, but it has to communicate that information to the client somehow, and the URI is really the only place to do it.  

> resource which should be secure.

I wasn't aware of the originator's name, but certainly agree with the intent.   

There's a huge problem with in-band negotiation of security if either (a) it's feasible for an attacker to get the client to downgrade to insufficient security, or (b) it's so much work for the client to negotiate good security that clients tend to be lazy and not bother to even try. 

One thing I find fairly annoying about URIs in that we'd really like to be able to attach attributes and/or constraints to a URI (like what the minimum security requirements should be) for the purpose of things like bookmarks, but we don't have a uniform URI syntax that lets us define such attributes and/or constraints while still being able to easily separate them from the name of the resource being referred to.

Keith

---

From: Ned Freed <[email-masked]>
Date: Fri, 04 Nov 2011 08:31:20 -0700 (PDT)

> things belongs in the URL; I don't think the scheme is a good place to

I'm in complete agreement with Harald on all of these points. And while it
would have been nice if URL syntax was less messy and more general, making
it easier to do these sorts of things in a consistent way, it quite simply
isn't and we have to make do with what we have.

				Ned

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Nov 2011 08:56:13 -0700

> isn't and we have to make do with what we have.

I don't have any commitment to the scheme. What's the best place?

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Nov 2011 09:06:07 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Rescorla
> Sent: Friday, November 04, 2011 8:56 AM
> To: Ned Freed
> Cc: Keith Moore; Keith Moore; Behave WG; [email-masked]
> Subject: Re: [rtcweb] URI schemes for TURN and STUN
> 

http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05
uses "?transport=", for example:

  turn://example.com?transport=tcp
  turns://example.com?transport=udp

-d

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Nov 2011 09:17:26 -0700

>   turns://example.com?transport=udp

The document uses opaque URI (there was a long discussion at the time about
this), so it is in fact:

turn:example.com?transport=tcp
turns:example.com?transport=udp

- -- 
Marc Petit-Huguenin

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Nov 2011 09:40:05 -0700

> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Friday, November 04, 2011 9:17 AM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Ned Freed'; 'Behave WG'; 'Keith Moore'; 'Keith
> Moore'; [email-masked]
> Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
> 
> >>>> things belongs in the URL; I don't think the scheme is a good
> place
> >> to
> >>>> encode it.
> >>>

Thanks for the correction.

(some examples in the I-D would be useful, to avoid mistakes like mine.)

-d

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk60EBIACgkQ9RoMZyVa61fG4wCeLR4SnIoXerj7ONxM6QeKgjZh
> rmoAmwbBUDmL6YOlnfH1sWsC6a6R+4Bz
> =Iqfa
> -----END PGP SIGNATURE-----

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Nov 2011 09:42:35 -0700

>  turns://example.com?transport=udp

I'm confused. I thought the idea was to distinguish TLS from non-TLS,
but you seem to be doing that in the scheme.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Nov 2011 09:49:32 -0700

>> (some examples in the I-D would be useful, to avoid mistakes like mine.)

Will do.  Thanks.

- -- 
Marc Petit-Huguenin

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Nov 2011 09:53:41 -0700

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Friday, November 04, 2011 9:43 AM
> To: Dan Wing
> Cc: Ned Freed; Keith Moore; Keith Moore; Behave WG; [email-masked]
> >> > would have been nice if URL syntax was less messy and more
> general,
> >> making
> >> > it easier to do these sorts of things in a consistent way, it
> quite
> >> simply

Harald said:

  URI needs to contain all the
  information you need in order to make contact with the service;
  you can't negotiate until you've made contact.

Keith has never liked using "S" in HTTPS (or other URIs).  *shrug*.
I think that ship sailed.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 05 Nov 2011 01:18:47 +0100

On 11/04/2011 04:56 PM, Eric Rescorla wrote:
> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed<[email-masked]>  wrote:
I like parameters, like this:

turn://user@host?proto=tcp

Quite hard to misunderstand, and quite easy to extend.

(Note: // is only allowed if what follows is [user[:pass]@]host - I 
don't recommend using the password, for the obvious reasons, but the 
syntax will allow it.)

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Nov 2011 07:30:51 -0700

> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't
> recommend using the password, for the obvious reasons, but the syntax will
> allow it.)

I don't see any security problem with that. The "break old
implementations" rationale
doesn't apply when we are defining a new URI scheme.

-Ekr

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sat, 5 Nov 2011 11:04:39 -0400

> doesn't apply when we are defining a new URI scheme.

I agree with this as well.  If we can get some consensus with this, I will update the next version of both the STUN and TURN URI Scheme drafts to include this format.

Regards,

Gonzalo

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 05 Nov 2011 08:14:56 -0700

On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote:
>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand <[email-masked]
>> <mailto:[email-masked]>> wrote:
> I agree with this as well.  If we can get some consensus with this, I will
> update the next version of both the STUN and TURN URI Scheme drafts to include
> this format.

Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already
doing it right (and had a lot of reviews back in 2008, before I split the
resolution mechanism and the syntax in two separate documents).

I know my email address does not contain the magical "cisco.com", but this is
getting ridiculous.

- -- 
Marc Petit-Huguenin

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sat, 5 Nov 2011 11:28:40 -0400

> resolution mechanism and the syntax in two separate documents).
I was under the impression (based on an exchange with Cullen) that you had no plans to pass user credentials in the URI scheme you were proposing. I'm perfectly OK with whatever the group decides. Nonetheless, the change makes change to me for one or both drafts.

> I know my email address does not contain the magical "cisco.com", but this is

I have no idea where this came from, so I'll choose to leave it alone.

Regards,

Gonzalo

> iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV1OYuSg3tN
> B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu
> =jYZJ

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 05 Nov 2011 08:45:05 -0700

On 11/05/2011 08:28 AM, Gonzalo Salgueiro wrote:
>>>>> <mailto:[email-masked]>
>> I was under the impression (based on an exchange with Cullen) that you had no
>> plans to pass user credentials in the URI scheme you were proposing.

Yes, and you can count me as opposing user credentials in *any* new URI.

>> I'm
>> perfectly OK with whatever the group decides. Nonetheless, the change makes
>> change to me for one or both drafts.
> 
> I know my email address does not contain the magical "cisco.com
> <http://cisco.com>", but this is
> getting ridiculous.
> 

- -- 
Marc Petit-Huguenin

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Nov 2011 12:45:26 -0700

On Sat, Nov 5, 2011 at 10:20 AM, Ned Freed <[email-masked]> wrote:
> Given your earlier characterization of the TCP/UDP/TLS distinction being
> a single axis, I assume you mean that you'd say:
>
>  turn://user@host?proto=tls
>
> and not
>
>  turns://user@host?proto=tcp
>
> I have to say I prefer the parameter approach, but I wonder if these really
> are along a single axis - is DTLS a possibility here?

TCP/TLS
UDP/DTLS
TCP/DTLS

Are all options. Also, it seems like you might want to run DCCP or SCTP
and those work with DTLS and {DTLS,TLS} respectively. So, probably
better to make the parameters separate.

-Ekr

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 05 Nov 2011 22:24:10 +0100

>don't recommend using the password, for the obvious reasons, but the 

As far as the requirements for URI schemes go, no, it is not necessary
to allow a user name or password. The 'http' scheme for instance prohi-
bits both, and the 'pop' scheme allows a user name but no password.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Nov 2011 17:36:34 +0100

On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote:
>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand<[email-masked]

Sorry, some of us were not on BEHAVE in 2008, and missed the previous 
discussion.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Nov 2011 17:38:08 +0100

> I know my email address does not contain the magical "cisco.com", but this is
Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names.
I still think this is doing it wrong.

                   Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Nov 2011 17:42:44 +0100

On 11/05/2011 06:20 PM, Ned Freed wrote:
>> place to
>> general, making
>> quite simply

I was thinking

    turn://<user>@<host>?proto=<udp, tcp or tls>

but thought that this was going too far into details.
> are along a single axis - is DTLS a possibility here?
DTLS is a possibility, if the TURN protocol is extended to support it, 
and would be a fourth parameter value. Currently it's not specified (AFAIK).

My opinion is that the URL needs to contain the context that the TURN 
client needs to know before it can contact the TURN server. There may be 
options that can reasonably be negotiated in the TURN channel setup 
procedure; those don't need to be in the URL.

My current reading is that with the current TURN spec, the initial 
packets sent by the user is different for the 3 cases TCP, UDP and TLS.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Nov 2011 17:45:01 +0100

> but thought that this was going too far into details.

Is not more appropriate to use "transport" rather than "proto"?

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Nov 2011 17:48:54 +0100

> bits both, and the 'pop' scheme allows a user name but no password.
Good riddance!

I see that http://tools.ietf.org/html/rfc3986#section-3.2.1 still 
defines it as part of the generic syntax, but as "deprecated".

It used to be a regularly used feature of HTTP, too, but that was long 
ago....

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 06 Nov 2011 08:58:45 -0800

On 11/06/2011 08:36 AM, Harald Alvestrand wrote:
> Sorry, some of us were not on BEHAVE in 2008, and missed the previous discussion.

This is not the problem.  The problem is that the authors of the new draft
continue to ignore a draft that is the result of BEHAVE, IESG, security,
gen-art, ops and other directorate reviews.  (To be fair, two employees of Cisco
I worked with in the past contacted me to see how to work on this but none of
the authors of the draft did).

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 06 Nov 2011 09:18:55 -0800

On 11/06/2011 09:59 AM, Ned Freed wrote:
> I concur, especially since two different security layers could be used for some
> transports in addition to none at all. The security layer needs to be specified
> as a parameter.

The current syntax was inspired by RFC 3261, but I can put some text about
different syntax in the spec for the purpose of the discussion[1].

What parameter name would you propose for that?

[1] Note that my point of view, and IMO the first thing that should be
discussed, is that a TURN URI is not needed for what RTCWEB wants to do.  Why is
it better to have a URI (on which we cannot put the password anyway), versus
having multiple individual string characters for the security level, transport,
host, port, login and password?

- -- 
Marc Petit-Huguenin

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sun, 6 Nov 2011 13:10:57 -0500

> the authors of the draft did).

I find it incredible I need to explain anything about ignoring your draft when in our draft it clearly states:
   We acknowledge the existence of
   draft-petithuguenin-behave-turn-uri-bis-04 document as a parallel
   effort in defining the URI scheme for TURN.  Awareness of this draft
   came late in the process and we have not had to time to reach out to
   the author of that memo and discuss opportunities to collaborate on a
   single document.  It is our intentions to do so.
The discussion you had with Cullen and Dan are known to us but we were pretty much finished both the STUN and TURN drafts by the time we found out about your draft. At this point we were waiting for you and Cullen to discuss the best way forward to meet the needs of WebRTC.  We are happy to combine forces or yield entirely, based on that discussion.

Regards,

Gonzalo

> iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzKwkQa19Uus
> 7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW
> =r7Po

---

From: Tina TSOU <[email-masked]>
Date: Mon, 07 Nov 2011 00:15:25 +0000

Ned,
In line...

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ned Freed
Sent: Sunday, November 06, 2011 9:59 AM
To: Harald Alvestrand
Cc: Eric Rescorla; Ned Freed; Keith Moore; Gonzalo Salgueiro; Keith Moore; Behave WG; [email-masked]
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN

I concur, especially since two different security layers could be used for some
transports in addition to none at all. The security layer needs to be specified
as a parameter.
[TT] Using two different security layers at the same time? Or one or the other?

				Ned
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave