IETF Logo Mail Archive

Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

Havard Eidnes <he@uninett.no> Mon, 20 February 2012 16:02 UTC

Return-Path: <he@uninett.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB421F86E0 for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 08:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 FrUxQVgDidZW for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 08:02:19 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id D302821F874C for <v6ops@ietf.org>; Mon, 20 Feb 2012 08:02:18 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 9D1833D0B4; Mon, 20 Feb 2012 17:02:16 +0100 (CET)
Date: Mon, 20 Feb 2012 17:02:16 +0100
Message-Id: <20120220.170216.446120856.he@uninett.no>
To: rbonica@juniper.net
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net>
References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net>
X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: marc.lampo@eurid.eu, v6ops@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2012 16:02:19 -0000

> The IESG has already approved this drat for publication.  However, I
> think that your comment is significant if you can make a case that
> the DNS information returned to the user is less trustworthy than it
> would have been had the authoritative DNS not been practicing
> whitelisiting.  Can you make this case?

"Less trustworthy" would be an imprecise euphemistic term to use in
this case.  Instead, the returned data would fail cryptographic
validation as performed by DNSSEC, and would therefore be discarded as
invalid ("incorrect") by a DNSSEC-validating resolver.

Therefore, it would seem to me that you can either do AAAA
whitelisting or DNSSEC, but not successfully do both.

Regards,

- Håvard

v2.23.0 | Report a Bug | By Email