Re: [secdir] Secdir review: http://www.ietf.org/id/draft-jiang-a6-to-historic-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 15 January 2012 02:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 866F021F84AF; Sat, 14 Jan 2012 18:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.568
X-Spam-Level:
X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 SXWxvtVuAxo6; Sat, 14 Jan 2012 18:52:09 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 956BB21F84AA; Sat, 14 Jan 2012 18:52:08 -0800 (PST)
Received: by eaad11 with SMTP id d11so614716eaa.31 for <multiple recipients>; Sat, 14 Jan 2012 18:52:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7pa9oy1GahKFJlFML1oAjbVF85gxb8d6jpb7CUlNAYo=; b=wlc+imrm5yRsCe8qWJAOBXgaOmtRkWExZah8SchnVL3X+wqNWi2d1HDZY7FD9ggH5B 3JWJdtZ+PF9m0HkpiPvWgZPiXPhytvkWyDgjI+WoI1mAR0OB5yCJjCHBgaz0S+utkTZK f5mdbvI5cKtMTcQG+cc2wdlpgR3dU9eJ0D1fo=
Received: by 10.213.19.139 with SMTP id a11mr2057071ebb.87.1326595926472; Sat, 14 Jan 2012 18:52:06 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id t1sm52096113eeb.3.2012.01.14.18.52.02 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 18:52:06 -0800 (PST)
Message-ID: <4F123F4B.3000403@gmail.com>
Date: Sun, 15 Jan 2012 15:51:55 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <CAMm+Lwjbc70Axi_4c14HOTC43Gvpb-2V=FPpe1ODUadGUV8ciw@mail.gmail.com>
In-Reply-To: <CAMm+Lwjbc70Axi_4c14HOTC43Gvpb-2V=FPpe1ODUadGUV8ciw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: drc@cloudflare.com, jiangsheng@huawei.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review: http://www.ietf.org/id/draft-jiang-a6-to-historic-00.txt
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: Sun, 15 Jan 2012 02:52:09 -0000

PHB,

Thanks for the review. See below.

On 2012-01-13 02:18, Phillip Hallam-Baker wrote:
> 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.
> 
> Overview
> 
> A6 was a proposed replacement for AAAA records. A6 has not achieved the
> anticipated level of support or provided the anticipated benefits in
> practice. This draft moves A6 to historic, deprecating use of A6 records.
> 
> 
> Comments:
> 
> Removing A6 removes a potential source of inconsistency and thus improves
> consistency.
> 
> One possible consequence of this particular change is that information that
> was previously expressible via the A6 mechanism will no longer be visible.
> While this is not necessarily good or bad from a security standpoint it is
> an issue that should be mentioned in the Security Considerations.

Can do.

> 
> Another possible security impact is that it will not be possible to divide
> up administrative duties in the manner originally envisaged in the A6
> proposal. While it is far from clear that this division is useful (or
> achievable) it should probably be noted. In particular it will not be
> possible to achieve renumbering of whole domains by changing one record.

Indeed; that was the hope when A6 was designed, and in fact it's because
the 6renum WG is taking a new look at this area that we decided it was
time to clear the decks.

> 
> It is quite possible that some domains will continue to employ A6 domains
> as an administrative convenience, generating the corresponding AAAA records
> as required. This case needs more consideration from a security point of
> view. It would be useful to require that such records be ignored by
> applications and preferably be blocked from external view.

We already recommend "Removing A6 handling from all new or updated host stacks"
and we could add a recommendation for apps to ignore them.

Blocking visibility of RRs is generally not something the DNS community
likes, though.

     Brian