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

Oleg Moskalenko <> Fri, 31 January 2014 22:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 103461A04EF for <>; Fri, 31 Jan 2014 14:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1kwDVL-SPuNC for <>; Fri, 31 Jan 2014 14:48:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c02::22b]) by (Postfix) with ESMTP id 4539B1A04E8 for <>; Fri, 31 Jan 2014 14:48:06 -0800 (PST)
Received: by with SMTP id g10so4797543pdj.30 for <>; Fri, 31 Jan 2014 14:48:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TzlffoWnI9hVp6egeEDowgv5ADBT673s6kAVU00qH0o=; b=I9Ta+7dEQsMpd4dgW3Bo9bMvr68RuScaA70aC8Y0WRyHrRuqaNyLIcRICSiFXpDQHr 3iVKDxc5NjhNGYJ5ZAAaHoloohofQ8Hn9qya6qfAp4lkAwZqonPb+H2+l4ir+c26fQJs rzKSceXKhRx7Aa+fY79U7P9JyVHsDfjhnBLzYCoHxYrm6W9vR2Jh/XIGBaR09saFb2A+ AVq4MgKjd04iuUqUI2jwl+xOTstlsEKzA8BNqYcLKurDxj8IAHosM+vxhss3zZRbskLX Wenl1jXM82wLkz6Sqphc+dTVIGCbD50zm2W2CijOlsdGxUpGnlRNVpuiVhTUyICsSNbK pZcA==
MIME-Version: 1.0
X-Received: by with SMTP id vc5mr23422323pbc.92.1391208482634; Fri, 31 Jan 2014 14:48:02 -0800 (PST)
Received: by with HTTP; Fri, 31 Jan 2014 14:48:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 31 Jan 2014 14:48:02 -0800
Message-ID: <>
From: Oleg Moskalenko <>
To: Alan Johnston <>
Content-Type: multipart/alternative; boundary="047d7b338f1d6a833f04f14bf76b"
Cc: "Gonzalo Salgueiro (gsalguei)" <>, "" <>
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: Fri, 31 Jan 2014 22:48:08 -0000

Hi Alan

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

On Fri, Jan 31, 2014 at 2: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.

It is saying that:

   TLS-over-UDP (referred to as DTLS [RFC6347
<>]) offers the same security
   advantages as TLS-over-TCP, but without the undesirable latency

 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.

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

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

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