Re: [secdir] Secdir review of draft-petithuguenin-behave-turn-uris-05

Marc Petit-Huguenin <marc@petit-huguenin.org> Mon, 19 August 2013 20:59 UTC

Return-Path: <marc@petit-huguenin.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDDA21F8540; Mon, 19 Aug 2013 13:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDArADSl0Hbo; Mon, 19 Aug 2013 13:59:03 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E87B521F9AE3; Mon, 19 Aug 2013 13:56:56 -0700 (PDT)
Received: from [IPv6:2601:9:4bc0:25:c46:df4a:a6e:6768] (unknown [IPv6:2601:9:4bc0:25:c46:df4a:a6e:6768]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8F21C20454; Mon, 19 Aug 2013 22:56:41 +0200 (CEST)
Message-ID: <52128687.4080506@petit-huguenin.org>
Date: Mon, 19 Aug 2013 13:56:39 -0700
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
References: <C0E0A32284495243BDE0AC8A066631A8172DD663@sjceml501-mbs.china.huawei.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A8172DD663@sjceml501-mbs.china.huawei.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 19 Aug 2013 14:05:55 -0700
Cc: "draft-petithuguenin-behave-turn-uris.all@tools.ietf.org" <draft-petithuguenin-behave-turn-uris.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-petithuguenin-behave-turn-uris-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2013 20:59:09 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Tina,

Thanks for the review, see my comments inline.

On 08/19/2013 10:41 AM, Tina TSOU wrote:
> Dear all,
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> 
> These comments were written primarily for the benefit of the security area 
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> 
> 
> Summary: This document is almost ready for publication aiming for Standards
> Track.
> 
> 
> 
> This document defines two URI schemes to provision the TURN Resolution
> Mechanism.
> 
> 
> 
> This document defines TURN Server URI syntax. It considers UDP/TCP/TLS 
> scenarios, facilitating applications like WEBRTC to use TURN Server to 
> accomplish NAT Traversal.
> 
> 
> 
> Major issues: None
> 
> 
> 
> Minor issues:
> 
> 
> 
> 1. The authors define the syntax for the turn/turns URI in ad hoc fashion, 
> copying definitions from RFC 3986 rather than using RFC 3986 directly. The 
> justification is that there is no need for hierarchy in the turn/turns
> URI.
> 
> 
> 
> In fact, hierarchy is introduced only within the path component described
> by RFC 3986. The turn/turns URI as defined in this document is achieved by
> use of the RFC 3986 form:
> 
> 
> 
> scheme ":" hier-part [ "?" query ] [ "#" fragment ]
> 
> 
> 
> with the following specific rules:
> 
> 
> 
> hier-part consists of the authority part and an empty path
> 
> 
> 
> userinfo and the succeeding '@' MUST be omitted from authority
> 
> 
> 
> the fragment portion is not present.
> 
> 
> 
> It is strongly recommended that this formulation be used, to bring the
> document into line with RFC 3986. Note that this implies adding double
> slash '//' after the scheme.

The // means after the scheme means that this is a hierarchical URI, which
does not make sense in this case as the concept of hierarchy is not applicable
to a TURN server.

I am in fact following the advice of RFC 4395 section 2.2:

"URI schemes that do not contain a conformant hierarchical structure
 in their <scheme-specific-part> SHOULD NOT use double slashes
 following the "<scheme>:" string."

The TURN URI is not using the userinfo part, the hier-part, the query part or
the fragment part, only the host and port parts and this is the reason why the
ABNF productions from RFC 3986 are copied and not simply referenced:  Using
references proved confusing to reviewers and implementers, as this made them
think that a TURN URI could be parsed with a hierarchical URI parser.

> 
> 
> 
> 2. The Security Considerations section correctly makes reference to RFC
> 5928, but perhaps does not make it clear that RFC 5928 Section 5 is
> essential reading. Could I suggest:
> 
> 
> 
> "Security considerations for the resolution mechanism are discussed in
> Section 5 of [RFC5928]. Note that that section contains normative text
> defining authentication procedures to be followed by turn clients when TLS
> is used."
> 

I will add this in -06.

Thanks.

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJSEoaEAAoJECnERZXWan7EXswQAK56Gc4ZjrypCVmn0kE7qRtD
i/H9rKx1XvrPonmHCat2UpysiU25sZnnm8QgxhHqYHfqWqndj/oFeTMTUgwR+rPs
T1x4Pmk7CgEYyQC4Eu+gUy63IQP3JaPT+2h4Vdi070Qy9k+ar3R47K+/VfeNCfa/
8B1drTW5yNkrR4lIVUd0ubNraGCmTi8reKn3jLtgGLqYi/s4Mo5BAlP0vu+xTwlU
43YaVxFvYeVulwNRoQ5gcPqtnyKM+AwEJf0rw4fvW+MjaipUMW7vS2EKgWASKddm
PnZnk7ai/nzQaTaFL6qJKz5RwzDyY/JU6gNPMhCry+0MShqreBtx58UknP1cTtJN
4Ng5wdot4BrfWiB/2OMTe8+RVqMVmU9L5Js9aLDuk7rDezyJLg93Vjv844sTSfr4
4vzgYA/uOcKRv+ysq65XsPufI8dSS4EMLkvbK86rghkf2gGRX+dX6j3Nf7YP4hwT
Hd86irS5kQ9VZkZsQvSF3q2XWPWyNlql7KGPT/BT6om5z8JjJYj8Qxeu46j8QmoI
W9YZ170qrXzPM8pF1JbOcM/sR2JVZyXQt4Qjfx8E9vOks1wvdubTVOCypWUnlDaj
gZsWc9QQEoDXxl/LKpWKNkuRqS1L9NG0Y23B54pbhsp/xs7Jx+VRFaDPmFgbYoZ9
KlI8PCRk1IFvyzljb2x0
=45Zn
-----END PGP SIGNATURE-----