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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 4 Feb 2014 09:53:53 +0000

I agree with Simon response, STUN over DTLS only makes sense from protocol design aspect.

The privacy problem mentioned below with STUN can be addressed by TURN itself, TURN server could also be used to learn server-reflexive candidate and there is no need wait for STUN servers to be upgraded. ICE connectivity checks use STUN which is a good indicator for an attacker to find that the 5-tuple could be used for media streams. So if privacy is a concern then only relayed candidates should be advertised in offer/answer.

-Tiru.
From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Monday, February 03, 2014 10:54 PM
To: Simon Perreault
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt

A few comments below to Oleg & Simon.

- Alan -

On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
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.

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.

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

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.

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