[secdir] SecDir Review of draft-ietf-dane-ops-12

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Fri, 10 July 2015 03:42 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 []) by ietfa.amsl.com (Postfix) with ESMTP id ADE4E1A87C8; Thu, 9 Jul 2015 20:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gK7KGPw8_E79; Thu, 9 Jul 2015 20:42:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C950F1A87C5; Thu, 9 Jul 2015 20:42:16 -0700 (PDT)
Received: from (EHLO lhreml405-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUZ96857; Fri, 10 Jul 2015 03:42:15 +0000 (GMT)
Received: from SZXEML428-HUB.china.huawei.com ( by lhreml405-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Fri, 10 Jul 2015 04:42:14 +0100
Received: from szxeml557-mbs.china.huawei.com ([]) by szxeml428-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 11:42:07 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "iesg@ietf.org" <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>, "draft-ietf-dane-ops.all@tools.ietf.org" <draft-ietf-dane-ops.all@tools.ietf.org>
Thread-Topic: SecDir Review of draft-ietf-dane-ops-12
Thread-Index: AQHQusJkWYK6y6gAhUWN1LafIW5+LQ==
Date: Fri, 10 Jul 2015 03:42:06 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A818C43CD4@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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/3hRxLWoZ5gu7cW4F0h-atEz1_AQ>
Subject: [secdir] SecDir Review of draft-ietf-dane-ops-12
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 10 Jul 2015 03:42:18 -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 that arrive in timely manner, and not significantly belated.

I've found this document well-written. I believe it is ready for publication modulo some small issues that can hopefully be addressed prior to publication:

**** Technical *****

* Meta: I would have liked to find (if anything, in an appendix) the rationale for he changes being proposed by this document. Since the changes are said to originate on operational experience, I think that codifying the lessons (problems found, and a rationale for the workarounds). There seems to be a bit of this throughout the document, but not for most of the changes proposed.

* Section 4.8, page 8:
> Therefore, when a TLS client
>    authenticates the TLS server via a TLSA record with usage DANE-EE(3),
>    CT checks SHOULD NOT be performed.

What are the valid reasons for performing th CT checks? If there are not any, why not make this requirement a "MUST NOT" instead?

* Section 5.1, page 10:
> Servers SHOULD NOT rely on
>    "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
>    data for raw public keys.

Same here.

* Section 7, page 17:
>    Though CNAMEs are illegal on the right hand side of most indirection
>    records, such as MX and SRV records, they are supported by some
>    implementations.  For example, if the MX or SRV host is a CNAME
>    alias, some implementations may "chase" the CNAME.  If they do, they
>    SHOULD use the target hostname as the preferred TLSA base domain as
>    described above (and if the TLSA records are found there, use the
>    CNAME expanded domain also in SNI and certificate name checks).

If CNAMES on the right hand side of most indirection records are illegal, why trying to process them in the first place?

* Section 9, page 21:
> This order SHOULD be configurable by the MTA
>    administrator. 

Please expand "MTA". Also, why make the explanation mail-specific?

* Section 13, page 26:
>    The signature validity period for TLSA records should also not be too
>    long.  Signed DNSSEC records can be replayed by an MiTM attacker
>    provided the signatures have not yet expired. 

Please expand "MiTM".

**** Nits *****

Section 1.1, Page 4:
>       difficult to host multiple Customer Domains at the same IP-
>       addressed based TLS service endpoint (i.e., "secure virtual
>       hosting").

s/addressed based/address-based/

Section 4.2, page 8:
> Publication of the server
>    certificate or public key (digest) in a TLSA record in a DNSSEC
>    signed zone by the domain owner assures the TLS client that the
>    certificate is not an unauthorized certificate issued by a rogue CA
>    without the domain owner's consent.

Avoiding the double-negation improves clarity... i.e., please change to "...is an authorized certificate issued by a rogue CA
    without the domain owner's consent"

* Section 5.1, page 9:

>    With DANE-EE(3) servers that know all the connecting clients are
>    making use of DANE, they need not employ SNI

I'm having trouble parsing this sentence... could you please take a look and tweak it if necessary?

Thank you,