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

"Tirumaleswar Reddy (tireddy)" <> Tue, 04 February 2014 09:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2065F1A03E7 for <>; Tue, 4 Feb 2014 01:53:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B1OzYy8plCCx for <>; Tue, 4 Feb 2014 01:53:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2DBF71A0388 for <>; Tue, 4 Feb 2014 01:53:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14432; q=dns/txt; s=iport; t=1391507636; x=1392717236; h=from:to:cc:subject:date:message-id:mime-version; bh=QhsyCET1mAZb6vz7GuksO7RKPiYyjhW3X5GupUqNChQ=; b=W1tdidnzj+3oNG6CdiANGa8H5nxls4U0EJMuVa+VbQLB23LvrSIpRvqb F1ederhupU4CbvlL8ANmHl150L8jPD0+Gk5C9a4UJihhomPJZymxlDl7A mA6+rap6zWY96r/COjVa0RitZ5nCmk2iP5C02bIiwlF2BKSi/mwleOMNn g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.95,778,1384300800"; d="scan'208,217"; a="17762178"
Received: from ([]) by with ESMTP; 04 Feb 2014 09:53:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s149rsuS026522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 09:53:54 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 03:53:54 -0600
From: "Tirumaleswar Reddy (tireddy)" <>
To: Alan Johnston <>, Simon Perreault <>
Thread-Topic: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt
Thread-Index: Ac8hjv+VvUmuJrPgQt2EUgCF1DuGLg==
Date: Tue, 04 Feb 2014 09:53:53 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242A74CBxmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Feb 2014 09:53:58 -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.

From: tram [] On Behalf Of Alan Johnston
Sent: Monday, February 03, 2014 10:54 PM
To: Simon Perreault
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 <<>> 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

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.

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->
tram mailing list<>