Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)

Charlie Perkins <charles.perkins@earthlink.net> Tue, 28 February 2017 21:32 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1F129532; Tue, 28 Feb 2017 13:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
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 yM0ITcY04gDs; Tue, 28 Feb 2017 13:32:39 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB6C1296FB; Tue, 28 Feb 2017 13:32:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1488317559; bh=fPffHNMWVirREtcdvQaSolRTQmh+jJi2wab6 n3IkerI=; h=Received:From:Subject:To:References:Cc:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=jOxgeg0C0WWkCfqamnD7ruCqqZGxEvzIgvHoRWwUr3mYsg ANviG1p1gOdd7xfcs5PsVUD6kAFV/ceQOiPS1QPw3vYBx6d/vB86RRtX2yBIWHRuf+6 Qbi9Yh0gBkLqBpJd2kmjyDqVyOysGFc9h2B05YQ91ZxiOo5WNrfAgDjHjCS7gZUJpPW g6FlTcAFgHYAo9Gf1UkJV1OjyhD30Kviv5Mea1aV++OnALm2jf5fR8SGq01s/MnCG3i 2YrpPwLof6qBgsWLDCF3csE9T7R2kOKjFXX+AJ+4cuxnWQ4RWvxCinEPgaGG6DFVlfW +DyrGaGEYF7fX8czBn7ew9954OAw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=jPNoZLRnVFaYjb4dy7k6bQYiSGMYxBAfKFxfpbd5mtGTIyaSxt5kjaV3fGYyfJEftWPE0S395miNEcRPexxTqJf3VXNuNYMeFKKgU1AfqKjpxT4G18NK1AOrsDfDzyMb/hlplGvbIe8fXmvoh5rbA6Aw3ppEAkZ8ZBrw2ijgidt5N5vYsbyD4BFY06s2KRP5XCg6ffvXnAdcJSRKbdNl/GNfs2zNfrlyCcf0K/BxJMEGKT3LKnq2y5B58A72aM/fdx2FdRvKFHU7/BSK3apKkapA31Y233Or4rzGRa9B6qnkvriIlIoECzmns0ABrcCvChF9u3EYZADzt9QkjtI4Kg==; h=Received:From:Subject:To:References:Cc:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1cipNh-0007q7-TX; Tue, 28 Feb 2017 16:32:26 -0500
From: Charlie Perkins <charles.perkins@earthlink.net>
To: dmm@ietf.org
References: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com>
Message-ID: <8a2e5094-228e-2848-7f6c-a911d3375291@earthlink.net>
Date: Tue, 28 Feb 2017 13:32:22 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------149FDB785DEF86B4EA5CD548"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7c48b874c56c2c2fcb81b7508dafb64cb350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/kc4s2svb-Dzq7LID8WmYUI2GkCc>
Cc: dmm-chairs@ietf.org
Subject: Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2017 21:32:42 -0000

Hello folks,

It has been suggested that the dmm WG members should to provide more 
support for the inclusion of the MNIDs that are listed in 
draft-ietf-dmm-4283mnids-04.

In order to resolve this issue, please send discussion to the [dmm] 
mailing list with thoughts about which of the types proposed in the 
draft are likely to require considerations about privacy when used in 
the Mobile Node Identifier option.  Also, for the proposed types, it has 
been requested to make some discussion about how their inclusion will 
help to improve the Internet.

Thanks in advance,
Charlie P.

On 2/15/2017 5:27 PM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dmm-4283mnids-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> I don't consider that merely mentioning that there are some
> privacy issues (maybe) is nearly sufficient here.  Instead I
> would argue that any of these identifier types that could have
> privacy implications need to be specifically justified or else
> dropped. By specifically justified, I mean that there ought be
> an argument (and a fairly holistic one) that the Internet is
> better, and not worse, if we define a codepoint that allows
> MIPv6 (and later, other protocols) to use that identifier.  I
> do accept that my position is perhaps innovative, in terms of
> IETF processes, so I'll split the discuss into two parts, one
> process oriented and mostly for the IESG, and the second
> relating to the content of the draft.
>
> (1) For the IESG: is it ok that we introduce (codepoints for)
> a slew of new long-term stable privacy-sensitive identifiers
> just because they might someday be needed, or do we need to
> have specific justification for defining such things? I would
> argue the latter, but that may need us to validate that there
> is IETF consensus for that somehow, and perhaps in the
> meantime hold on to this draft. Part of my reasoning is that
> once we define such codepoints (e.g. for IMSIs) then that
> inevitably means that other protocols, and not just MIPv6,
> will do the same eventually, so accepting this draft basically
> means accepting that we end up commonly and perhaps
> carelessly, passing such highly-sensitive information about on
> the Internet in many protocols and in many contexts.  My
> argument here I think does adhere to various of our BCPs that
> do argue for security and privacy, but I do also accept that
> this may be novel and to some extent goes against another of
> our generally accepted ideas which is that we benefit from
> folks documenting things even if those things are sub-optimal
> in various ways. So I'd argue this is a real case for an IESG
> discussion - I know what I think, but what do the rest of you
> think?
>
> (2) For the authors: to the extent you are willing to, and
> want to get ahead of the discussion on point (1) above, can
> you in fact provide an argument, for each of the identifiers
> here that have privacy-sensitivity, that the Internet is better
> overall if we define these codepoints knowing that if we do
> define a way to represent e.g. an IMSI in MIPv6 that is likely
> to be copied elsewhere? Note for the authors: I think it's
> entirely fine for you to do nothing pending the discussion of
> point (1) above, if that's your preference.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> While I'm entirely sympathetic to Mirja's discuss point, I
> don't think that a statement here can really constrain how
> these identifiers, once they are defined, are used in other
> protocols. While there is a chance that some IESG sometime
> might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt
> if <that> identifier is used" the chances that a future IESG
> notice this isn't that high, but it's also even more likely
> that the designers of future protocols will successfully argue
> that since not all identifiers are privacy sensitive, their
> specific protocol need not adhere to the SHOULD. In the end, I
> think that should or SHOULD will be ineffective.
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>