Re: [Pearg] [Secdispatch] Numeric IDs: Update to RFC3552
Benjamin Kaduk <kaduk@mit.edu> Fri, 19 April 2019 01:25 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7B120183; Thu, 18 Apr 2019 18:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wPaUQjnVKH7M; Thu, 18 Apr 2019 18:25:12 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9BFAB12003F; Thu, 18 Apr 2019 18:25:12 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J1P7vT014596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2019 21:25:09 -0400
Date: Thu, 18 Apr 2019 20:25:07 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Fernando Gont <fgont@si6networks.com>, pearg@irtf.org, IETF SecDispatch <secdispatch@ietf.org>, "Iván Arce (Quarkslab)" <iarce@quarkslab.com>, secdispatch-chairs@ietf.org
Message-ID: <20190419012507.GB95327@kduck.mit.edu>
References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> <CABcZeBOy6MB0OG2cs=EE6hWB4pXBuNzW=LcQ+1dKmJzHBOUR-g@mail.gmail.com> <bc733114-6f97-532b-02d5-2730e834340a@si6networks.com> <CABcZeBPr2rfVkib684Gz4uCPWtFc4trwusJxNRJ6EPPpA=d0QA@mail.gmail.com> <f3607e4f-c805-3cb5-110b-f09cb8748577@si6networks.com> <CABcZeBPwVDiMKSR-w-oq16FN__j8c8dEqutL3Z92SXKF5RT_Uw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBPwVDiMKSR-w-oq16FN__j8c8dEqutL3Z92SXKF5RT_Uw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/EAKaPBqrZBBNclgxE4sOxIRNoiU>
Subject: Re: [Pearg] [Secdispatch] Numeric IDs: Update to RFC3552
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 01:25:15 -0000
On Thu, Apr 18, 2019 at 05:01:17PM -0700, Eric Rescorla wrote: > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont <fgont@si6networks.com> wrote: > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont <fgont@si6networks.com > > > <mailto:fgont@si6networks.com>> wrote: > > > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > <fgont@si6networks.com <mailto:fgont@si6networks.com> > > > > <mailto:fgont@si6networks.com <mailto:fgont@si6networks.com>>> > > wrote: > > > > > > > > Folks, > > > > > > > > At the last secdispatch meeting I presented our I-D > > > > draft-gont-predictable-numeric-ids. > > > > > > > > >From the meeting discussion, it would seem to me that there > > > is support > > > > for this work. > > > > > > > > It would also seem to me that part of this work is to be > > > pursued in an > > > > appropriate IRTF rg, while the update to RFC3552 > > > > (draft-gont-numeric-ids-sec-considerations) should be pursued > > > as an > > > > AD-sponsored document. > > > > > > > > > > > > I'm somewhat skeptical on an update to 3552; the proposed set of > > > things > > > > to be improved seems unclear. > > > > > > Can you please state what's unclear? > > > > > > > > > I understand the list of things in your document. However, there have > > > been proposals for a larger revision to 3552. > > > > There was an effort to revise RFC3552. It just didn't happen. Looks like > > trying to boil the ocean wasn't the best idea. > > > > Yes. > > > > > > > It's a total of 9 pages. If you remove abstract, boilerplate, and > > references, you end up with ~4 pages. In fact, the update (and > > indispensable text) is that in Section 5, and boils down to: > > > > ---- cut here ---- > > 5. Security and Privacy Requirements for Identifiers > > > > Protocol specifications that specify transient numeric identifiers > > MUST: > > > > 1. Clearly specify the interoperability requirements for the > > aforementioned identifiers. > > > > 2. Provide a security and privacy analysis of the aforementioned > > identifiers. > > > > 3. Recommend an algorithm for generating the aforementioned > > identifiers that mitigates security and privacy issues, such as > > those discussed in [I-D.gont-predictable-numeric-ids]. > > ---- cut here ---- > > > > Eh, I think something like this would have been OK in 3552; I'm not > sure that it's necessary to add at this point to the list of things that > 3552 considers. > > > > > > That said, this document is *updating* RFC3552, rather than a > > revision > > > of RFC3552. Therefore, the content in this document wouldn't become > > part > > > of RFC3552, necessarily. > > > > > > > > > Well, the semantics of "Updates" would be somewhat confusing here. > > > Certainly I don't think that this document is something we need to > > > transitively incorporate into 3552, but I care a lot less about the > > > contents of this header than I do about whether 3552 should be updated > > > to include this material. > > > > I do think RFC3552 should be updated as indicated (this stuff is general > > enough to be covered there). > > > > That said, the high-order bit here is to do something to prevent the bad > > history we have wrt numeric ids from repeating itself. > > > > If the whole point is that you'd like the "Updates: 3552 (if approved)" > > header to be removed (along with references to "updating RFC3552"), > > please say so. > > > No, that's not my point. As I said, I don't think we should publish a new > version > of 3552 with this material or similar material in it. I don't much care one > way > or the other whether this document is published, and while I don't think > marking > it as updating 3552 is that helpful, I'm not going to die on that hill > either. Do you care to state an opinion on "Updates: 3552" vs. an additional document in BCP 72 (vs. both or none)? Thanks, Ben
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Eric Rescorla
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Fernando Gont
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Fernando Gont
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Eric Rescorla
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Fernando Gont
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Benjamin Kaduk
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Hannes Tschofenig
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Fernando Gont
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Fernando Gont
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Eric Rescorla
- Re: [Pearg] [Secdispatch] Numeric IDs: Update to … Fernando Gont