Subject: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt]

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Apr 2014 03:54:51 -0600

I did not receive any comment on this proposal, so I am resubmitting it here:

Following the discussion in the TRAM session in London about the domain/ip
address handling for STUN over DTLS, we discussed what to do in the draft, and
came with an alternate solution that could be better than the conclusion in
the session (which was to forbid IP addresses).  Because IP addresses are
already accepted when TLS will be used with a STUN/TURN URI, that would
require a document modifying 7064/65 to change that also for DTLS.

As a reminder, here's the text in RFC 5389:

  "The client
   MUST verify the identity of the server.  To do that, it follows the
   identification procedures defined in Section 3.1 of RFC 2818
   [RFC2818].  Those procedures assume the client is dereferencing a
   URI.  For purposes of usage with this specification, the client
   treats the domain name or IP address used in Section 8.1 as the host
   portion of the URI that has been dereferenced.  Alternatively, a
   client MAY be configured with a set of domains or IP addresses that
   are trusted; if a certificate is received that identifies one of
   those domains or IP addresses, the client considers the identity of
   the server to be verified."

The problem here is when the IP address has been resolved before the URI was
created, which will be the case most of the time in the WebRTC server.  What
we would suggest is to to add a new member in the RTCIceServer dictionary to
carry the domain name (names?) to validate in case IP addresses are used in
the STUN/TURN URI (pretty much like what was done for the username and password).

Comments?

On 03/24/2014 01:37 PM, Gonzalo Salgueiro (gsalguei) wrote:
> Hi -
> 
> We have posted two new versions of the draft today. The -00 was the WG
> adopted with text unchanged from draft-petithuguenin-tram-stun-dtls-00.
> 
> This -01 version addresses the open issues we came to consensus on during
> the meeting in London.
> 
> Changes <http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-01>
> from -00 to -01 are:
> 
> - Updated the mandatory cipher suites. - Added a new open item to determine
> if we want to specify favoring cipher suites which support PFS over non-PFS
> cipher suites. - Closed remaining opening items from previous draft.
> 
> 
> We will be sending some emails shortly to discuss a few open issues we'd
> like to tackle before an -02.
> 
> Thanks,
> 
> Gonzalo
> 
> On Mar 24, 2014, at 3:26 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the TURN Revised and Modernized
>> Working Group of the IETF.
>> 
>> Title           : Datagram Transport Layer Security (DTLS) as Transport 
>> for Session Traversal Utilities for NAT (STUN) Authors         : Marc
>> Petit-Huguenin Gonzalo Salgueiro Filename        :
>> draft-ietf-tram-stun-dtls-01.txt Pages           : 14 Date            :
>> 2014-03-24
>> 
>> Abstract: This document specifies the usage of Datagram Transport Layer 
>> Security (DTLS) as a transport protocol for Session Traversal Utilities
>> for NAT (STUN).  It provides guidances on when and how to use DTLS with
>> the currently standardized STUN Usages.  It also specifies modifications
>> to the STUN URIs and TURN URIs and to the TURN resolution mechanism to
>> facilitate the resolution of STUN URIs and TURN URIs into the IP address
>> and port of STUN and TURN servers supporting DTLS as a transport
>> protocol.
>> 
>> 
>> The IETF datatracker status page for this draft is: 
>> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/
>> 
>> There's also a htmlized version available at: 
>> http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-01
>> 
>> A diff from the previous version is available at: 
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-01
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at: 
>> ftp://ftp.ietf.org/internet-drafts/
>> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Apr 2014 03:59:31 -0600

An issue that was discussed in London was ALPN registration in the DTLS draft.
 After discussion, we think that this is not specific to DTLS, so perhaps it
is a better idea to have this registration either in a separate document or in
the future STUN-bis.

Comments?

On 03/24/2014 01:37 PM, Gonzalo Salgueiro (gsalguei) wrote:
> - Updated the mandatory cipher suites. - Added a new open item to
> determine if we want to specify favoring cipher suites which support PFS
> over non-PFS cipher suites. - Closed remaining opening items from previous
> draft.
> 
> 
>> directories. This draft is a work item of the TURN Revised and
>> Modernized Working Group of the IETF.
>> 

- -- 
Marc Petit-Huguenin

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Apr 2014 09:26:26 -0400

Le 2014-04-04 05:54, Marc Petit-Huguenin a écrit :
> What

So if the client always has access to the domain name, why wouldn't it 
always resolve by itself? I would be very tempted to write this simple 
pseudocode:

char *hostname;
if (is_a_domain_name(uri_host))
	hostname = uri_host;
else
	hostname = rtciceserver_host;
resolve_and_connect(hostname);

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Apr 2014 09:37:03 -0400

> is a better idea to have this registration either in a separate document or in

Doesn't matter. What goes in STUN-bis is irrelevant. For what it's 
worth, we could even decide that STUN-bis will include and obsolete 
stun-dtls completely. STUN-bis is a longer-term, broader scope effort. 
We need functional [D]TLS today, and that includes ALPN IMHO.

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 4 Apr 2014 17:58:53 +0000

Understood.  Nonetheless, even if not a part of STUNbis, it doesn't seem it should be buried in STUNoDTLS.  Shall we produce a dedicated draft for this?

-G

On Apr 4, 2014, at 9:37 AM, Simon Perreault <[email-masked]> wrote:

> Doesn't matter. What goes in STUN-bis is irrelevant. For what it's worth, we could even decide that STUN-bis will include and obsolete stun-dtls completely. STUN-bis is a longer-term, broader scope effort. We need functional [D]TLS today, and that includes ALPN IMHO.
> 
> Simon
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Apr 2014 14:00:32 -0400

> Understood.  Nonetheless, even if not a part of STUNbis, it doesn't seem it should be buried in STUNoDTLS.  Shall we produce a dedicated draft for this?

My preference would be for "buried in STUNoDTLS". :) But I'm open to 
arguments for a dedicated draft.

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 4 Apr 2014 18:09:24 +0000

On Apr 4, 2014, at 2:00 PM, Simon Perreault <[email-masked]> wrote:

> My preference would be for "buried in STUNoDTLS". :) But I'm open to arguments for a dedicated draft.

My position is that the ALPN reg is entirely independent of STUNoDTLS, which is why we considered more contextually relevant for the broader STUNbis effort.  A standalone dedicated ALPN reg doc to point to seems cleaner to me, but I'm open to WG decision on this.

-G

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 4 Apr 2014 13:17:19 -0700

If ALPN is really independent of DTLS, I see no reason why they have to be
combined in the draft document that was created solely for the DTLS feature
introduction for STUNl.

On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) <
[email-masked]> wrote:

> >> Understood.  Nonetheless, even if not a part of STUNbis, it doesn't
> seem it should be buried in STUNoDTLS.  Shall we produce a dedicated draft
> for this?
> >
> My position is that the ALPN reg is entirely independent of STUNoDTLS,
> which is why we considered more contextually relevant for the broader
> STUNbis effort.  A standalone dedicated ALPN reg doc to point to seems
> cleaner to me, but I'm open to WG decision on this.
>
> -G
>
> >
> > Simon
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 8 Apr 2014 05:46:28 +0000

Yup, ALPN will be common for both TLS and DTLS. I see that http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2 and http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 also discuss ALPN. we will need one place holder draft talking about all the necessary ALPN identifiers.

-Tiru
From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Saturday, April 05, 2014 1:47 AM
To: Gonzalo Salgueiro (gsalguei)
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt]

If ALPN is really independent of DTLS, I see no reason why they have to be combined in the draft document that was created solely for the DTLS feature introduction for STUNl.

On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) <[email-masked]<mailto:[email-masked]>> wrote:

-G

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

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 8 Apr 2014 05:59:26 +0000

Agreed.  We can try and put something together.

-G

On Apr 8, 2014, at 1:46 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

> On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) <[email-masked]> wrote:
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 7 Apr 2014 23:13:04 -0700

I think that ALPN draft has to be a separate dedicated to ALPN draft. We
already have TLS in TURN. The DTLS draft simply corrects that asymmetry and
makes DTLS on the same level as TLS. That is logically a separate task from
adding ALPN to both TLS and DTLS. I'd keep those two things as sequential
separate drafts. Mixing them is introducing a sort of mess into the process.

Oleg

On Mon, Apr 7, 2014 at 10:46 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Yup, ALPN will be common for both TLS and DTLS. I see that
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2and
> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 also
> discuss ALPN. we will need one place holder draft talking about all the
> necessary ALPN identifiers.
>
>
>
> -Tiru
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Oleg Moskalenko
> *Sent:* Saturday, April 05, 2014 1:47 AM
> *To:* Gonzalo Salgueiro (gsalguei)
> *Cc:* Simon Perreault; [email-masked]
> *Subject:* Re: [tram] ALPN Registration [was Re: I-D Action:
> draft-ietf-tram-stun-dtls-01.txt]
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 11:57:17 -0400

On 4/8/14 1:46 AM, Tirumaleswar Reddy (tireddy) wrote:
> Yup, ALPN will be common for both TLS and DTLS.

*Why* would ALPN be common for TLS and DTLS? The characteristics of 
those transports are very different, so that it would be very rare for 
one higher level protocol to be usable over both.

	Thanks,
	Paul

> I see that
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2
> and http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3
> also discuss ALPN. we will need one place holder draft talking about all
> the necessary ALPN identifiers.
>
> -Tiru
>
> *From:*tram [mailto:[email-masked]] *On Behalf Of *Oleg Moskalenko
> If ALPN is really independent of DTLS, I see no reason why they have to
> be combined in the draft document that was created solely for the DTLS
> feature introduction for STUNl.
>
> On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> On Apr 4, 2014, at 2:00 PM, Simon Perreault <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> seem it should be buried in STUNoDTLS.  Shall we produce a dedicated
> draft for this?
>  >
> [email-masked] <mailto:[email-masked]>

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 8 Apr 2014 10:24:24 -0700

TLS and DTLS are indeed two different protocols with different
characteristics. But in application to TURN, both carry, in most cases, the
same content (the same application-level protocol suite): RTP, RTCP, SRTP.
So I suppose that ALPN will be very similar for both TLS and DTLS. Then,
why not consider them together ?

On Tue, Apr 8, 2014 at 8:57 AM, Paul Kyzivat <[email-masked]> wrote:

> *Why* would ALPN be common for TLS and DTLS? The characteristics of those
> transports are very different, so that it would be very rare for one higher
> level protocol to be usable over both.
>
>         Thanks,
>         Paul
>
>  I see that

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 13:52:22 -0400

On 4/8/14 1:24 PM, Oleg Moskalenko wrote:
> characteristics. But in application to TURN, both carry, in most cases,
> the same content (the same application-level protocol suite): RTP, RTCP,
> SRTP. So I suppose that ALPN will be very similar for both TLS and DTLS.
> Then, why not consider them together ?

This really wasn't intended as a TRAM-specific comment.
It is a comment about ALPN in general. ISTM that people are trying to 
over-generalize it where it doesn't apply.

Note that RTP over TCP is technically a different protocol than RTP over 
UDP - it requires framing to be added.

When you look at where ALPN is defined 
(draft-friedl-tls-applayerprotoneg) it is intended for use with TLS over 
TCP. In that context some protocol that is intended for use over an 
unreliable message oriented transport would be nonsense.

	Thanks,
	Paul

> On Tue, Apr 8, 2014 at 8:57 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     those transports are very different, so that it would be very rare
>     for one higher level protocol to be usable over both.
>
>              Thanks,
>              Paul
>
>         I see that
>         http://tools.ietf.org/html/__draft-hutton-rtcweb-nat-__firewall-considerations-03#__section-4.2
>         <http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2>
>         and
>         http://tools.ietf.org/html/__draft-thomson-rtcweb-consent-__00#section-3
>         <http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3>
>         *From:*tram [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Oleg Moskalenko
>         *Cc:* Simon Perreault; [email-masked] <mailto:[email-masked]>
>         draft-ietf-tram-stun-dtls-01.__txt]
>
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>         On Apr 4, 2014, at 2:00 PM, Simon Perreault
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         _________________________________________________
>         tram mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
>
>
>
>
>         _________________________________________________
>         tram mailing list
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
>
>
>     _________________________________________________
>     tram mailing list
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 8 Apr 2014 13:18:00 -0700

please see inside

> over-generalize it where it doesn't apply.

OK. We were discussing it in TRAM context.

> UDP - it requires framing to be added.

STUN protocol is providing that framing, already. Both UDP TURN and TCP
TURN are using the same "framing" format. So, in TRAM context, there is no
difference between RTP-inside-TURN-inside-TLS and
RTP-inside-TURN-inside-DTLS (if we are not talking about RFC 6062 TCP TURN).

>
> When you look at where ALPN is defined (draft-friedl-tls-applayerprotoneg)
> it is intended for use with TLS over TCP. In that context some protocol
> that is intended for use over an unreliable message oriented transport
> would be nonsense.
>

Well, the reality is that RTP is used in TCP TURN quite often and this is
part of WebRTC. So I am not sure that there is anything wrong in using ALPN
with DTLS-TURN.

Thanks,
Oleg

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 16:32:58 -0400

On 4/8/14 4:18 PM, Oleg Moskalenko wrote:
> please see inside
>
>
> On Tue, Apr 8, 2014 at 10:52 AM, Paul Kyzivat <[email-masked]
>     It is a comment about ALPN in general. ISTM that people are trying
>     to over-generalize it where it doesn't apply.
>
>
>     Note that RTP over TCP is technically a different protocol than RTP
>     over UDP - it requires framing to be added.
>
>
> TURN are using the same "framing" format. So, in TRAM context, there is
> no difference between RTP-inside-TURN-inside-TLS and
>     (draft-friedl-tls-__applayerprotoneg) it is intended for use with
>     TLS over TCP. In that context some protocol that is intended for use
>     over an unreliable message oriented transport would be nonsense.
>
>
> Well, the reality is that RTP is used in TCP TURN quite often and this
> is part of WebRTC. So I am not sure that there is anything wrong in
> using ALPN with DTLS-TURN.

I agree that this seems to work fine for TURN - *if* a common ALPN 
registry makes sense over all transports.

I'll pursue my issues in a more appropriate forum.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 9 Apr 2014 11:03:15 +0000

Looks like the issue of including DTLS in the ALPN draft (http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05) has been discussed in TLS (See http://www.ietf.org/mail-archive/web/tls/current/msg11534.html) and hopefully some clarification on use of ALPN will be added to the next update.

I assume that it would be necessary to use different ALPN identifiers if only because it will probably be necessary to point to two different RFC's for STUN/TURN over TLS and DTLS.

Andy

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 08 April 2014 21:33
> To: Oleg Moskalenko
> Cc: [email-masked]
> >         characteristics. But in application to TURN, both carry, in
> most
> >         cases,
> >         SRTP. So I suppose that ALPN will be very similar for both
> TLS
> >         and DTLS.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 9 Apr 2014 12:54:53 +0000

ALPN can also be sent for DTLS, it's only a doc mistake and errata for that is raised in http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=3917

-Tiru

> From: tram [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> Sent: Wednesday, April 09, 2014 4:33 PM
> To: Paul Kyzivat; Oleg Moskalenko
> Cc: [email-masked]
> Looks like the issue of including DTLS in the ALPN draft
> (http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05) has been
> discussed in TLS (See http://www.ietf.org/mail-
> archive/web/tls/current/msg11534.html) and hopefully some clarification on
> use of ALPN will be added to the next update.
> 
> I assume that it would be necessary to use different ALPN identifiers if only
> because it will probably be necessary to point to two different RFC's for
> STUN/TURN over TLS and DTLS.
> 
> Andy
> 
> 
> 
> 
> > > RTP-inside-TURN-inside-DTLS (if we are not talking about RFC 6062
> > > TCP
> > TURN).
> > >
> > >

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 18 Apr 2014 08:10:20 -0600

On 4/4/14, 7:26 AM, Simon Perreault wrote:
>> What we would suggest is to to add a new member in the
>> RTCIceServer dictionary to carry the domain name (names?) to
>> validate in case IP addresses are used in the STUN/TURN URI
>> (pretty much like what was done for the username and password).
> 
> So if the client always has access to the domain name, why wouldn't
> it always resolve by itself?

Well, the point is that when the server is providing an URI that
contains an IP address (probably because it does not want the TURN
client in the browser to spend time doing a DNS resolution), then the
client does not have the domain name, and so cannot verify the
certificate.  Passing the domain name in the js code, and from here to
the TURN client implementation through the RTCIceServer dictionary
will permit to verify it (AFAIK the js code does not have access to
the certificate, so the verification cannot be done in the application)

Note that we will have the same issue with DANE, that will need to get
the domain name to securely retrieve the TLSA RR and, unless we had a
boolean, a DNS query will also be required here.

What was decided at the meeting was to forbid IP addresses in URIs,
but I want to be sure that this is still the consensus (as that will
be a MUST NOT use IP address in the document).

> I would be very tempted to write this simple pseudocode:
> 
> char *hostname; if (is_a_domain_name(uri_host)) hostname =
> uri_host; else hostname = rtciceserver_host;

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 22 Apr 2014 14:04:41 +0000

Apologize for the delay (day job and stuff...), but based on this discussion, we have just submitted a draft registering a STUN ALPN protocol identifier. Review comments welcome.

There are two things we need WG direction on:

(1) We have an open item that requires discussion:
   
   In various offline discussions some have expressed a desire
   to add an additional ALPN protocol identifier for TURN (see IANA
   Considerations below for example registration).  ALPN can be used
   more granularly to externally identify more of the protocol variants
   and their different properties (i.e., STUN and TURN over TLS/DTLS).
   The advantage in dividing it this way is that these different forms
   can be externally identified (obviously, there isn't any inherent
   value in the different identifiers from within the TLS
   handshake).There are two main disadvantages. the first is that this
   two application protocol approach may make implementations more
   complicated/confusing.  The second is that there may be difficulty in
   differentiating the two with ALPN when TURN was specifically designed
   to be able to run on the same port as STUN usage (in section 13 of
   RFC 5389).  Section 4.1.1.2 of RFC 5245 explicitly says that "If the
   Allocate request is rejected because the server lacks resources to
   fulfill it, the agent SHOULD instead send a Binding request to obtain
   a server reflexive candidate."  Does that prove there is no need to
   differentiate TURN and STUN request on UDP/TCP or TLS and now DTLS?
   Are there sufficiently meaningful differences between the usages to
   warrant separate STUN and TURN ALPN identifiers?

(2) How do we progress this draft? Create a new milestone and adopt as a TRAM WG item or is best handled as an AD-sponsored individual draft?

Thanks,

Gonzalo

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 23 Apr 2014 15:56:44 +0000

Folks - 

We are planning to close on this open issue in the draft.  Appreciate any final comments as we are planning to publish the next version in the next few days.

More inline...

On Apr 18, 2014, at 10:10 AM, Marc Petit-Huguenin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 

In London the WG decided we should forbid ip addresses. The following text is proposed to address this (note that equivalent text is proposed for TURN URI as well):

"The <host> value MUST be used when using the rules in Section 7.2.2
of [RFC5389] to verify the server identity.  A STUN URI containing an IP
address MUST be rejected, unless the domain is provided by the same
mechanism that provided the STUN URI, and that this domain name can be
passed to the verification code."

Note that a bit of wiggle room is provided if there is an alternate way to pass the domain name to the (D)TLS verifier (CA or DANE). This was added in case of modification of the WebRTC API, but still ensuring that the domain name can be verified in all cases.

Sound OK?

Thanks,

Gonzalo

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTUTJMAAoJEMUNRP98lsiX08oIAJJ/pJ1sHIEaSPqhPGJMBwgT
> 6N1uLj6op3h56M7h8VIWhr3LPb4erMILd3TBIn29abpQDHQtHdRDmVBYmItZwCKi
> 01d1AQmVhiKPuaOH+XGk4bguNwIiF6mdgLvpxjswR3THE6AiD5NsYBcZBeXSWUxn
> bqOTQisHCuROYXwjfn4T/xftpM4bHc14ImeSjLZSu13ZBiNwif5Q2//lMAKeEtzP
> QnOrFR9patF2qyVuq1yHldYEwxwmINF7DZhMyudyy6koWkXzIDb7+BGLtlS3yGG9
> 34SuSBVnXfgmnV5e5WjeNBbblLCrj1A5rvmvB0ElSoxwz4WOVX9cWfdPR9r1IKg=
> =Ynxe
> -----END PGP SIGNATURE-----
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Apr 2014 12:10:34 -0400

> Note that a bit of wiggle room is provided if there is an alternate way to pass the domain name to the (D)TLS verifier (CA or DANE). This was added in case of modification of the WebRTC API, but st…

Works for me!

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 29 Apr 2014 12:42:07 +0000

Submitted draft is 
http://www.ietf.org/internet-drafts/draft-patil-tram-alpn-00.txt

-Prashanth

On 4/22/14 7:34 PM, "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
wrote:

>Apologize for the delay (day job and stuff...), but based on this
>discussion, we have just submitted a draft registering a STUN ALPN
>protocol identifier. Review comments welcome.
>
>(2) How do we progress this draft? Create a new milestone and adopt as a
>TRAM WG item or is best handled as an AD-sponsored individual draft?
>
>
>Thanks,
>
>Gonzalo
>
>
>
>><[email-masked]> wrote:
>> 
>><[email-masked]> wrote:
>>