[secdir] Secdir review of draft-hallambaker-tlsfeature-09

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Wed, 13 May 2015 02:13 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6E1A9039; Tue, 12 May 2015 19:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 C-omHnmZkLcj; Tue, 12 May 2015 19:13:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A47B1A9006; Tue, 12 May 2015 19:13:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY95700; Wed, 13 May 2015 02:13:27 +0000 (GMT)
Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 03:13:26 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Wed, 13 May 2015 10:13:19 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-hallambaker-tlsfeature-09
Thread-Index: AQHQjSJgcDug1ZCtTEeq/KRqufv8Kg==
Date: Wed, 13 May 2015 02:13:18 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A818AC7184@szxeml557-mbs.china.huawei.com>
References: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com>
In-Reply-To: <97FFF87E-5CFC-42BB-90A8-29DBE30C7772@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.87.91]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/S2H5GN4IFHcZUW0cOIQ1URS-g_8>
Cc: "draft-hallambaker-tlsfeature.all@tools.ietf.org" <draft-hallambaker-tlsfeature.all@tools.ietf.org>
Subject: [secdir] Secdir review of draft-hallambaker-tlsfeature-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 13 May 2015 02:13:35 -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.

In the intro, you refer to a number of attacks against TLS. Please provide references.


Section 1 and 2:
>    In order to avoid the confusion that would occur in attempting to 
>    describe an X.509 extension describing the use of TLS extensions, in 
>    this document the term 'extension' is reserved to refer to X.509v3 
>    extensions and the term 'feature' is used to refer to a TLS 
>    extension.
> 
> 2. Purpose
> 
>    The purpose of the TLS feature extension is to prevent downgrade 
>    attacks that are not otherwise prevented by the TLS protocol.

You should probably clarify in the terminology section what you mean by "TLS feature extension".


Section 3.3.1:

>    A CA SHOULD NOT issue certs with a TLS feature extension unless there
>    is an affirma

Please expand the acronym.


Thank you,
Tina