[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/