Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02

Ted Lemon <ted.lemon@nominum.com> Fri, 25 July 2014 14:12 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 278181A0352 for <mif@ietfa.amsl.com>; Fri, 25 Jul 2014 07:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 QVABzjWusGbm for <mif@ietfa.amsl.com>; Fri, 25 Jul 2014 07:12:08 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D25C1A0316 for <mif@ietf.org>; Fri, 25 Jul 2014 07:12:08 -0700 (PDT)
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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D42041B8908 for <mif@ietf.org>; Fri, 25 Jul 2014 07:12:07 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A592A190052; Fri, 25 Jul 2014 07:12:07 -0700 (PDT)
Received: from nat64.meeting.ietf.org (31.130.238.53) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Jul 2014 07:12:07 -0700
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: <E96BEAE3-909A-4D6B-BF41-FD45E155A4FE@gmx.com>
Date: Fri, 25 Jul 2014 10:12:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <9DFCB6BC-5565-4B98-8BA4-3BBBD49B1CAD@nominum.com>
References: <CANF0JMCKAM2htrjFHM+76cZ+agW9Z1JbfrDaFxcmFz5_z=RPTw@mail.gmail.com> <E96BEAE3-909A-4D6B-BF41-FD45E155A4FE@gmx.com>
To: Ian Farrer <ianfarrer@gmx.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [31.130.238.53]
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/KhnOTQjIknIaxJJku2anN_JGJgE
Cc: MIF Mailing List <mif@ietf.org>, Margaret Wasserman <margaretw42@gmail.com>
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02
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: Fri, 25 Jul 2014 14:12:10 -0000

On Jul 25, 2014, at 10:02 AM, Ian Farrer <ianfarrer@gmx.com> wrote:
> I'm concerned about this for a couple of reasons. It brings up a requirement for a very complex mechanism between the PvDs so that individual PvD configuration paramaters can indictate their applicability to other PvDs and also for a PvD to accept parameters from other PvDs. Then, there's the security implications of this.
> I think that this really blurs the overall architecture of containing PvD configuration and think that it should be removed.

+1

> This may be too prescriptive about the format which is used for the PvD. Of the 6 formats proposed in kkbg-mpvd-id, only three of them are potentially meaningfully human-readable (UTF-8, FQDN, NAI). What would be good here is to place no expectation on the PvD ID itself being readable, but allow for additional PvD ID specific meta-data to be added which is human readable. Additional meta-data types can the be defined as required for other PvD selection mechanisms.
> This avoids 'overloading' the function PvD ID itself, which should just be a unique id.

This can be used as a sort of social engineering attack.  Not clear that it's a good idea.