IETF Logo Mail Archive

Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC

Ted Lemon <Ted.Lemon@nominum.com> Tue, 03 February 2015 18:31 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5162E1A1A32; Tue, 3 Feb 2015 10:31:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7pdgmPe4hQC; Tue, 3 Feb 2015 10:31:02 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877C91A1B9B; Tue, 3 Feb 2015 10:31:02 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 577AEDA011E; Tue, 3 Feb 2015 18:31:02 +0000 (UTC)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 220C353E08B; Tue, 3 Feb 2015 10:31:02 -0800 (PST)
Received: from [172.19.131.154] (12.130.117.24) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 3 Feb 2015 10:26:58 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi>
Date: Tue, 03 Feb 2015 12:26:48 -0600
Content-Transfer-Encoding: quoted-printable
Message-ID: <FBE72B61-28E1-456B-BF3C-1B6C9C4A7D38@nominum.com>
References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <A48A040C-F8C3-4E97-AF97-CD80DD19C3CD@iki.fi> <ECA36B14-039B-4842-B492-632E8FC5F0C5@nominum.com> <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi>
To: Markus Stenberg <markus.stenberg@iki.fi>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [12.130.117.24]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/FXZmvQbvOAUF1I5redlJ-b9oOQM>
Cc: "mif@ietf.org List" <mif@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Feb 2015 18:31:06 -0000

On Feb 3, 2015, at 9:09 AM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
> Fair enough; I guess just splitting the dual stack PVDs if encountered (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. As I personally consider authentication mostly bogus, this is not really a problem for me :)

To be clear, the authentication we're talking about here, at least generally, is not intended to assert that the node receiving it can trust it without question.   It merely asserts that the information came from a particular source, which the node may or may not trust.   That's what the text you were commenting on was for, actually.

> So final suggestion - get rid of DANE, get rid of TLS, and probably rework the text in that paragraph a bit to make it simpler. As-is, both DANE and TLS mention seem superfluous.

I'm skeptical about this--I think it's good to mention DANE.   DNSSEC is in effect a PKI, but it's quite a bit different than the other common PKI example.   How about "a PKI, for example DNSSEC/DANE or X.509?"   That way we don't lose the mention of DNSSEC, but keep it open to other PKIs.

v2.23.0 | Report a Bug | By Email