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

Oleg Moskalenko <mom040267@gmail.com> Fri, 31 January 2014 22:48 UTC

Return-Path: <mom040267@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103461A04EF for <tram@ietfa.amsl.com>; Fri, 31 Jan 2014 14:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kwDVL-SPuNC for <tram@ietfa.amsl.com>; Fri, 31 Jan 2014 14:48:06 -0800 (PST)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4539B1A04E8 for <tram@ietf.org>; Fri, 31 Jan 2014 14:48:06 -0800 (PST)
Received: by mail-pd0-f171.google.com with SMTP id g10so4797543pdj.30 for <tram@ietf.org>; Fri, 31 Jan 2014 14:48:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.68.237.133 with SMTP id vc5mr23422323pbc.92.1391208482634; Fri, 31 Jan 2014 14:48:02 -0800 (PST)
Received: by 10.68.147.131 with HTTP; Fri, 31 Jan 2014 14:48:02 -0800 (PST)
In-Reply-To: <CAKhHsXE7mOqxwR6j3ndzHBeL2NNL_bMUZ1o_5UCJuWH9kJ1xmg@mail.gmail.com>
References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> <CAKhHsXE7mOqxwR6j3ndzHBeL2NNL_bMUZ1o_5UCJuWH9kJ1xmg@mail.gmail.com>
Date: Fri, 31 Jan 2014 14:48:02 -0800
Message-ID: <CALDtMrLJeoWDMOzwftiEMmQhHYC9x7n6oMuyBTSHZHe_f-Ph7g@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b338f1d6a833f04f14bf76b"
Cc: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt
X-BeenThere: tram@ietf.org
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=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 <alan.b.johnston@gmail.com>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
<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.


>
> 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
TURN-over-DTLS.

Regards,
Oleg


>
>
>