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

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Mon, 19 August 2013 17:41 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 569A921F9974; Mon, 19 Aug 2013 10:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ARbUquxLiror; Mon, 19 Aug 2013 10:41:25 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id D263211E82AF; Mon, 19 Aug 2013 10:41:21 -0700 (PDT)
Received: from (EHLO lhreml203-edg.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUN30799; Mon, 19 Aug 2013 17:41:19 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com ( by lhreml203-edg.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 18:40:30 +0100
Received: from SJCEML402-HUB.china.huawei.com ( by lhreml403-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 18:41:16 +0100
Received: from SJCEML501-MBS.china.huawei.com ([]) by sjceml402-hub.china.huawei.com ([]) with mapi id 14.01.0323.007; Mon, 19 Aug 2013 10:41:12 -0700
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-petithuguenin-behave-turn-uris-05
Thread-Index: Ac6dA0VAOItBp4XNQVOu2ZUd/rwVdg==
Date: Mon, 19 Aug 2013 17:41:11 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A8172DD663@sjceml501-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8172DD663sjceml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-petithuguenin-behave-turn-uris.all@tools.ietf.org" <draft-petithuguenin-behave-turn-uris.all@tools.ietf.org>
Subject: [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 17:41:30 -0000

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.

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

Thank you,