Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 31 Jan 2014 15:32:25 +0000

Folks - 

As mentioned during the authoring of the charter, we have published a draft to satisfy the milestone for "DTLS transport for TURN".

Feedback/comments much appreciated.  If time permits we will try and publish an -01 prior to the draft deadline.

Thanks,

Gonzalo

On Jan 31, 2014, at 10:00 AM, [email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Datagram Transport Layer Security (DTLS) as Transport for Traversal Using Relays around NAT (TURN)
>        Authors         : Marc Petit-Huguenin
>                          Gonzalo Salgueiro
> 	Filename        : draft-petithuguenin-tram-turn-dtls-00.txt
> 	Pages           : 9
> 	Date            : 2014-01-31
> 
> Abstract:
>   This document specifies the usage of Datagram Transport Layer
>   Security (DTLS) [RFC6347] as a transport protocol between a Traversal
>   Using Relays around NAT (TURN) [RFC5766] client and a TURN server.
>   It also specifies modifications to the TURN URIs [RFC7065] and to the
>   TURN resolution mechanism [RFC5928] to facilitate the resolution of
>   TURN URIs into the IP address and port of TURN servers supporting
>   DTLS as a transport protocol.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00
> 
> 
> 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/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 31 Jan 2014 09:30:59 -0800

I have a comment:

section 6 "Implementation status": On the TURN server side, there is a
number of open-source TURN servers that have been playing with DTLS
protocol implementation idea, for years (and I know at least one private
implementation). Our TURN server fully supports DTLS at the same level as
TLS:

http://code.google.com/p/rfc5766-turn-server/

Regards,
Oleg

On Fri, Jan 31, 2014 at 7:32 AM, Gonzalo Salgueiro (gsalguei) <
[email-masked]> wrote:

> Folks -
>
> As mentioned during the authoring of the charter, we have published a
> draft to satisfy the milestone for "DTLS transport for TURN".
>
> Feedback/comments much appreciated.  If time permits we will try and
> publish an -01 prior to the draft deadline.
>
> Thanks,
>
> Gonzalo
>
>
>
>
> >        Title           : Datagram Transport Layer Security (DTLS) as
> Transport for Traversal Using Relays around NAT (TURN)
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 31 Jan 2014 10:45:12 -0700

> http://code.google.com/p/rfc5766-turn-server/

Please send me the RFC6982 template filled, and I'll add it to the next revision.

Thanks.

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 31 Jan 2014 12:38:53 -0800

As we are using TURN mostly for WebRTC these days, may be it is worth
mentioning how the TURN DTLS relates to DTLS-SRTP used as TURN payload in
WebRTC. In the WebRTC TURN use case, we have DTLS-inside-DTLS tunneled, in
a sense; and probably it makes sense to mention that those are two
independent DTLS sessions: one is a DTLS session between the client and the
TURN server, and the second session is a client-to-client session tunneled
inside the first session, with "use_srtp" DTLS extension. The TURN DTLS
does not need and does not support "use_srtp" extension.

I do not think that there must be a recommendation on avoiding double-DTLS.
My opinion is that avoiding double-DTLS has low priority and may not be
achieved easily; it may have some importance only from the MTU point of
view (two DTLS overheads with a video RTP traffic may present a problem
when near-MTU payload is used).

---

From: Alan Johnston <[email-masked]>
Date: Fri, 31 Jan 2014 16:22:13 -0600

Marc & Gonzalo,

This draft looks good - no major issues.  Here's a few comments for things
to consider.

Section 1 explains why we don't want to use TURN over TLS.  Might be good
to say why we want to use TURN over DTLS.  Such as: confidentiality between
TURN client and server which can protect against the limitations of the
long term auth method, and privacy for TURN attributes.

Also, this draft talks exclusively about TURN over DTLS.  What about STUN
over DTLS?  I was thinking about DTLS for STUN for gathering reflexive
candidates for setting up a data channel-only Peer Connection.  Having DTLS
between the STUN client and server could  provide confidentiality for STUN
attributes.  Does this make sense?  if not, are we sure there are no other
STUN use cases?

In the last paragraph of Section 3 mentions the application name of "udp".
 I think this correct as it refers to the SRV RR syntax, but I wanted to be
sure this was correct and not a typo.

Section 7 could use some text describing the security benefits of TURN over
DTLS to help motivate why we all want this extension.

- Alan -

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 31 Jan 2014 14:48:02 -0800

Hi Alan

I'll add my opinion... please see below in the text:

On Fri, Jan 31, 2014 at 2:22 PM, Alan Johnston <[email-masked]>wrote:

> to say why we want to use TURN over DTLS.
>

It is saying that:

   TLS-over-UDP (referred to as DTLS [RFC6347
<http://tools.ietf.org/html/rfc6347>]) offers the same security
   advantages as TLS-over-TCP, but without the undesirable latency
   concerns.

 and I suppose that this is accurate enough explanation. This is exactly
what we want, for media traffic - TLS without TCP.

Such as: confidentiality between TURN client and server which can protect
> against the limitations of the long term auth method, and privacy for TURN
> attributes.
>

well, all that plus confidentiality of the payload.

> attributes.  Does this make sense?  if not, are we sure there are no other

I am not sure that STUN over DTLS makes sense. While we do support it in
our project, I do not see what information to be protected in STUN
requests. It can be mentioned, done and implemented, but I fail to see the
point. There is no secure non-public information in the STUN Binding
request and response.

> Section 7 could use some text describing the security benefits of TURN
> over DTLS to help motivate why we all want this extension.
>

I suppose that the desire to have encrypted UDP for media traffic is all
that matters and it provides all (or almost all) motivation for
TURN-over-DTLS.

Regards,
Oleg