[secdir] Secdir review: http://www.ietf.org/id/draft-jiang-a6-to-historic-00.txt
Phillip Hallam-Baker <hallam@gmail.com> Thu, 12 January 2012 13:18 UTC
Return-Path: <hallam@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 CE44D21F8592; Thu, 12 Jan 2012 05:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
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 Rpl42IQ3ZWVb; Thu, 12 Jan 2012 05:18:26 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC06A21F85AC; Thu, 12 Jan 2012 05:18:25 -0800 (PST)
Received: by obcwo10 with SMTP id wo10so900434obc.31 for <multiple recipients>; Thu, 12 Jan 2012 05:18:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LIsVtywh4gm5fp5GTNF/D3TMwJ5Sb8tMuBtbYaA6CFw=; b=uhPaEwTC5ZvdDQsihOaoXA4ZnbLaoaSdcYwqr3w5mvMyWMhfGtdbQ0/yfuDDeXwzEx eZtI7J/zEzHvOob/S2k+X9I7ZvGHKMPls31QSvQdiHRfTLcfDOxARBVmqabLBNedVkXY AOu0E6NSRd7mN/XQtTf5eR8xd2nLFrt89Ih5o=
MIME-Version: 1.0
Received: by 10.182.72.74 with SMTP id b10mr2878372obv.69.1326374305509; Thu, 12 Jan 2012 05:18:25 -0800 (PST)
Received: by 10.182.45.134 with HTTP; Thu, 12 Jan 2012 05:18:25 -0800 (PST)
Date: Thu, 12 Jan 2012 08:18:25 -0500
Message-ID: <CAMm+Lwjbc70Axi_4c14HOTC43Gvpb-2V=FPpe1ODUadGUV8ciw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: secdir@ietf.org, iesg@ietf.org, jiangsheng@huawei.com, drc@cloudflare.com, brian.e.carpenter@gmail.com
Content-Type: multipart/alternative; boundary="f46d0447a08f51b27e04b654954e"
Subject: [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: Thu, 12 Jan 2012 13:18:26 -0000
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. 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. 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. -- Website: http://hallambaker.com/
- [secdir] Secdir review: http://www.ietf.org/id/dr… Phillip Hallam-Baker
- Re: [secdir] Secdir review: http://www.ietf.org/i… Brian E Carpenter