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

Markus Stenberg <markus.stenberg@iki.fi> Thu, 05 February 2015 09:13 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3984B1A007F; Thu, 5 Feb 2015 01:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
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 zY7xSElnn0yT; Thu, 5 Feb 2015 01:13:27 -0800 (PST)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 81CAC1A0059; Thu, 5 Feb 2015 01:13:27 -0800 (PST)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8F2EA00EA272B; Thu, 5 Feb 2015 11:13:22 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <CACurXJgeCgLuAJOaxtO47Uh_osgk7WsP-1F-h0VvO5kL+xZxqA@mail.gmail.com>
Date: Thu, 05 Feb 2015 11:13:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <66BBE1F3-A36E-4A75-8844-6CCE9469735B@iki.fi>
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> <FBE72B61-28E1-456B-BF3C-1B6C9C4A7D38@nominum.com> <CACurXJgeCgLuAJOaxtO47Uh_osgk7WsP-1F-h0VvO5kL+xZxqA@mail.gmail.com>
To: Dmitry Anipko <dmitry.anipko@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/covu1Va8t1eKIst6VADZxdZFFAE>
X-Mailman-Approved-At: Thu, 05 Feb 2015 08:51:51 -0800
Cc: Markus Stenberg <markus.stenberg@iki.fi>, "mif@ietf.org List" <mif@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2015 09:13:30 -0000

On 5.2.2015, at 6.25, Dmitry Anipko <dmitry.anipko@gmail.com> wrote:
> My reading is that there is a consensus to fix the name misspelling :-), but I could not quite read whether the PKI question got resolved. Markus, can you please comment whether the modification Ted worded would address your concern?

Sorry, I got sidetracked to writing security a audit document and never got back. We all have our guilty pleasures..

Anyway, haha ;) Guess we agree about something at least!

> > 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.

If simplification is not desired, I guess we can work that in too.

DANE is just about binding a (DNS) label + port + protocol using various selectors to a X.509 certificate (either CA or end node one).

Text in question:

   If authentication is done using a public key mechanism such as a TLS
   certificate or DANE, authentication by itself is not enough since
   theoretically any PvD could be authenticated in this way.  In
   addition to authentication, the node would need configuration to
   …

I am not sure where this DNS label + port + protocol combination would be derived from this case, but admittedly (say) using DHCPv6 or something might make sense in this case.

So.. my proposed version:

   If authentication is done using a public key mechanism such as 
   PKI certificate chain validation or DANE, authentication by itself is not enough since
   theoretically any PvD could be authenticated in this way.  In
   addition to authentication, the node would need configuration to

As the text talks of public key authentication mechanisms, I think PKI certificate chain validation and DANE both qualify. The old text’s ’TLS certificate’ is just weird to me, although I understand the idea is fundamentally the same.

Cheers,

-Markus