Re: [Secdispatch] Numeric IDs: Update to RFC3552

Eric Rescorla <ekr@rtfm.com> Fri, 19 April 2019 00:01 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA72120359 for <secdispatch@ietfa.amsl.com>; Thu, 18 Apr 2019 17:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 2i1_jqvFBRCX for <secdispatch@ietfa.amsl.com>; Thu, 18 Apr 2019 17:01:58 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF251120248 for <secdispatch@ietf.org>; Thu, 18 Apr 2019 17:01:57 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id a28so2871221lfo.7 for <secdispatch@ietf.org>; Thu, 18 Apr 2019 17:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZR06E1KKi5fk9z6VbFWIOqyBg6/3600xLE1kv6N4gA=; b=b3xc0+s0t0xaDlDyyaV4tJpkGl26T9jPinwi5LcpA/TCKPhM+wYjir3MdKx8wGhHH4 ayoRmNRJII0YeWsmRhl1Oxddq60ASNw/DzMo8nOg1iuS6Q7APErLxJeWu0FTdMtQkiDi CHMivaoth+D6Yy0vt2N0CjedU2u6ZmJodxyQr/wDJ77/iwuV9WSegzgh+KH+ew0abvmM jAfSCHTOxEmJpKhTeiTijbF9Y2+EO8hCm/lNl8+Cst0Yc3pTUKB5JgjyLgP7067a4The aNKFMXogO/Zcr9IUdleB9X9OntyVj9X2JKaNso9elT0p0WbRvTZ0pVmEQ3JZmd86FspG bFMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fZR06E1KKi5fk9z6VbFWIOqyBg6/3600xLE1kv6N4gA=; b=nZVung+MuYDJ4frD7uAV9GZSGk/f0JyX3k691tbvtFytKwmhnnFRP4RYglr/6LK3cp fVSigBdad0VcMsNboAaPoqXd5Ft8XruE+aiY5xux98t/E+AjlHBahpWeTaDipcKylaHk LAbJUWQhuLknJh87DBPxInYVK/kiL855ws749vrxUxLDWcPJwi5kHrdCrs6QxmeN1fX7 cBgwJfr1x368I7EUR6nkAOt0F5BHgz0JxYCOOXVcbEty7LLP5cTVDHIMFcGIEz/wAAzp hvyAcVJn2VMVVgNDQalYaJEbo7xEkq5cLr8YdPlf5HX69my0m+64xlyv8cOOaCFfTgXB lI+Q==
X-Gm-Message-State: APjAAAUnAPjToBaIFIO+yVkBk+wIsQGjDoekJOBRCFbk/bk9IVQrrLIK k2ZQy99RxsiOkj4pAaaGHx+p/PQk0hUFpRkszaVllw==
X-Google-Smtp-Source: APXvYqy9z+5EeVagtlO3+rIoSI1xyQCC9z2c95QHHCV/UFPVOqmBacpNHpsLo81YB7PkeUXqOUf3vj77MEcPKCYGK8Y=
X-Received: by 2002:ac2:55b2:: with SMTP id y18mr477213lfg.133.1555632115987; Thu, 18 Apr 2019 17:01:55 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <f3607e4f-c805-3cb5-110b-f09cb8748577@si6networks.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 18 Apr 2019 17:01:17 -0700
Message-ID: <CABcZeBPwVDiMKSR-w-oq16FN__j8c8dEqutL3Z92SXKF5RT_Uw@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= <iarce@quarkslab.com>, IETF SecDispatch <secdispatch@ietf.org>, pearg@irtf.org, secdispatch-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000accd0e0586d6d31f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/wuYar5-P1UGggBEOifGNVZf45dg>
Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 00:02:00 -0000

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.

-Ekr