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

From: Simon Perreault <[email-masked]>
Date: Mon, 03 Feb 2014 10:53:10 -0500

Le 2014-01-31 17:48, Oleg Moskalenko a écrit :
>     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?
> 
> 
> 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.

It may not make operational sense, but it makes total protocol design sense.

UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is
just a set of new opcodes, and it inherits STUN's transports. So this
draft should apply exclusively to STUN. TURN could be mentioned in
passing, e.g. "by the way, TURN can make use of this new transport too."

(One caveat being TURN *channels*, about which this draft should be very
explicit.)

Now, whether clients or servers use DTLS for Binding requests, that's a
completely orthogonal question. A few words could be said about that in
an "Operational Considerations" section.

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: Alan Johnston <[email-masked]>
Date: Mon, 3 Feb 2014 11:23:55 -0600

A few comments below to Oleg & Simon.

- Alan -

On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault <[email-masked]
> wrote:

> > the point. There is no secure non-public information in the STUN Binding
Well, in the post-Snowden era, we need think carefully about this.  First
of all, STUN binding requests can indicate that an Internet user is
preparing to establish a real-time communications session.  This could be
useful information to an attacker or eavesdropper.  Secondly, additional
information in STUN attributes, such as ORIGIN could leak other information.

Also, remember that SRTP doesn't encrypt the RTP header, and thus leaks
information about the type of session being established and the fact that a
real-time session is taking place.  One day we might want to run SRTP over
DTLS to hide this information.

Essentially, in this new world, STUN & TURN take the place of a signaling
protocol, so providing the highest level of security for them can be
useful. I would be very disinclined to rule out STUN over DTLS right now.

> passing, e.g. "by the way, TURN can make use of this new transport too."
I agree that we need to be very clear about this in drafts, and not just
talk about TURN because that is where we see the most important use case.
 The name of this proposed working group is a little unfortunate in that
sense, since we will really be doing STUN extensions most of the time.

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 3 Feb 2014 09:33:50 -0800

Alan and Simon, I have no objections. If we are talking about STUN as a
protocol (not just Binding request) then that's totally fine.

Thanks
Oleg

On Mon, Feb 3, 2014 at 9:23 AM, Alan Johnston <[email-masked]>wrote:

> On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault <
> [email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 04 Feb 2014 11:13:38 -0700

Alan,

We will releasing a new version before the end of this week that adds STUN
over DTLS and all your and other participants suggestions.

Thanks.

On 01/31/2014 03:22 PM, Alan Johnston wrote:
> 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 -
> 
> 
> On Fri, Jan 31, 2014 at 9:32 AM, Gonzalo Salgueiro (gsalguei) 
> <[email-masked] <mailto:[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
> 
> 
> 
> 
> On Jan 31, 2014, at 10:00 AM, [email-masked] 
> <mailto:[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
> <http://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] <mailto:[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
> 
> _______________________________________________ tram mailing list 
> [email-masked] <mailto:[email-masked]> 
> _______________________________________________ tram mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tram
> 

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

---

From: Alan Johnston <[email-masked]>
Date: Tue, 4 Feb 2014 12:25:40 -0600

Great!  Looking forward to it.

We are getting ready to revise the STUN Origin draft as well, so if anyone
has any additional comments, now would be a good time to send them to the
list.

- Alan -

On Tue, Feb 4, 2014 at 12:13 PM, Marc Petit-Huguenin <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alan,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJS8S3QAAoJECnERZXWan7E77kQALVgYnDi2N6iw6Cyji0pEK40
> Mk80+8sgOamfJIcI39tiFuc0f+5ytNZ9coc4WhQ/NExtOu9O9cuk2ttka5pz0asr
> axxfrCLg6o6VEoRSiF3L0lBGr4uPewiu6Q1bD2a2MEvvI4OVVQIhVcipYpa0Fei5
> Ns+mXm+QVx6U+281oFVmi2zZgWjZX1zJIA2k6TmFAaPGnrtZFgMCzlWKm0lFauYq
> TglwwwkbUREnvXCG+M4OLqB3LSin2gdnpWsFEkBrMcQ7DEdtynwWvGxsofM4QnJ5
> eYDHPsX5O1xSaie1xU0m5kaozO0G0FTqrZgaRmCR95LnnCalgVto+izfdr//efLB
> eC3NHPB19QuIeHxlJapy62bwPykNKxZ6WJDfa3/kugSxbQsNpmBS6sOrjY0gBYbC
> y2c2pmbWHR07xzKRbNymWxxMcqag0IburLECSRxqZYHlulG0mSb3e8yq2ALyMPnl
> PE37TiH0o7UYoverGgLVw/U02uklDOmXt18j8Dq68CNleH/rPotdhOSBzXTlxD2j
> 9ufIK+jGTaGQNALCMDKmWVkAuqT0OnO06YsQT8ZmZCnob/cn7G0dWuy+46ra76/f
> 1WCTj+ibKH1Wn+AezJ2N8XJIGDRmBBUfXDzmNYAdWcVDsdwXyVcqRRRtrJE73KAo
> sdqSpG3rBFZLg+rLtUnk
> =caou
> -----END PGP SIGNATURE-----
>