From nobody Thu Apr 18 15:03:18 2019 Return-Path: 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 C80F0120454 for ; Thu, 18 Apr 2019 15:03:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 yxyTkKx8KK2V for ; Thu, 18 Apr 2019 15:03:13 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B827312040B for ; Thu, 18 Apr 2019 15:03:10 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 692A383529; Fri, 19 Apr 2019 00:03:01 +0200 (CEST) To: Eric Rescorla Cc: IETF SecDispatch , secdispatch-chairs@ietf.org, pearg@irtf.org, =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 18 Apr 2019 23:50:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 22:03:17 -0000 On 18/4/19 15:45, Eric Rescorla wrote: > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > 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? We have 30+ years of history of screwing up numeric identifiers in the protocols we specify. Just to name a few: * TCP ISNs * TCP ephemeral ports * DNS TxIDs * IPv4 Frag IDs * IPv6 Frag IDs * IPv6 IIDs * NTP port numbers * NTP timestamps * TCP timestamps ... and the list can continue. We are trying, for once and for all, to act proactively in this respect, to avoid repeating the same history in every protocol we specify, and every implementation that comes up. > I don't think that the material in this document should be added to > 3552, as the purpose of 3552 is not really to go into that kind of > detail about any specific topic. What I would expect is that RFC3552 helps prevent us from coming up with vulnerable implementations. Clearly, the history of flawed IDs seems to indicate that we are doing something wrong. At the time of this writing, it seems that RFC3552 is the document that draft/RFC authors are required to read when it comes to how to do a security analysis of their document. So I am curious why you think this doesn't belong to RFC3552. 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. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 18 16:10:10 2019 Return-Path: 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 E3B96120418 for ; Thu, 18 Apr 2019 16:10:04 -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=unavailable 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 npgnLMpQOVNX for ; Thu, 18 Apr 2019 16:10:02 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 92968120140 for ; Thu, 18 Apr 2019 16:09:59 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t4so3269000ljc.2 for ; Thu, 18 Apr 2019 16:09:59 -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=sEYEMm84h3igtMKzB2xfgQJ7xJpK71RGldxJmcFuIrY=; b=S0qrAxahJ1UElm1B1fGO795GD7bos3Dunf/0eJkwpIHGjovFe3K6OBR6RQiUS7rNhu 9Nm8yxa0hZSnhaoHzhqQhmkjPww1+iI+APnCO6kVa2poYLevpO29f4D2CSKIdI9CvBkN 0cJDkqEYWk14iFyBRJ6uYProg2vFkGsAXAulWhAtuTOmkk6GiZ7j41dMFS0CCbP1laRo /v5aPm50TPZi97n+Ey5T/Trq3s65M66KZtwFgiZLFK+h8DGvU5x8I3QEsCKFpZru/HJX TC/kV/iIWgXOnbSKN7fQ3ZvHS411kPHhANMMEKMh5En+MrHsYYkubsSpy35iG4eni9gA rj9A== 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=sEYEMm84h3igtMKzB2xfgQJ7xJpK71RGldxJmcFuIrY=; b=XDf0jSqoUhps50nI5CA/Wkf1NRaKl5GFh1iPL81eukDTNmVEXQ07+FcyumI6Fi9pzI 7qKgrKEtr+LtzyWe9X7mOT4R3Q2f6Dz9er07efxfpYVkbhwF5TN09P1o5PXWX4HRQyjD 9Hmq+sFA/H5jA9retQGF7SEHMtu16o+n+5banFPwYUUbCT09kdUwKRJqN2739UgAKXmw eHEAD8e+fd1c5tSWSK4Q7kgQqU2a3N2RL2mEwooT54zBUiEju2CJmQI81mRnNwEhilZy OiwOhsc1KowBQGFiq+qjNDSSKa5G4UFa/I16M2eT2j2QcXjB4Cs2PsuNahNBpo8pAwvU /c4Q== X-Gm-Message-State: APjAAAV94dzJv4c3KDDGxdd7BOAtGe5RcuHppNRiiVLuEnZuAqAKifXA oLI5G3BWBRgBXuPiZcR/ugTlg/i7xOqSaDhZojb3Iw== X-Google-Smtp-Source: APXvYqzNFDLi4dRO5mmwNGyb8V2r6trFjdT3xd7sRSHMsEkiIJkIf22+qBo7yeeTAgn6vltMkWJ5n2vcBn4swO3h/0Q= X-Received: by 2002:a2e:81da:: with SMTP id s26mr426236ljg.86.1555628997590; Thu, 18 Apr 2019 16:09:57 -0700 (PDT) MIME-Version: 1.0 References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> In-Reply-To: From: Eric Rescorla Date: Thu, 18 Apr 2019 16:09:19 -0700 Message-ID: To: Fernando Gont Cc: =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000cdd5860586d619db" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 23:10:09 -0000 --000000000000cdd5860586d619db Content-Type: text/plain; charset="UTF-8" On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont wrote: > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > 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. The proposed set of such revisions is unclear, and it's not clear to me why your document fits into such a revision. > > I don't think that the material in this document should be added to > > 3552, as the purpose of 3552 is not really to go into that kind of > > detail about any specific topic. > > What I would expect is that RFC3552 helps prevent us from coming up with > vulnerable implementations. This is not the purpose of 3552. Rather, it is to document what is required in a security considerations section in general (the threat model, an overview of common issues, etc.) rather than to go into detail about a specific kind of attack. Otherwise, the amount of detail would become impractical. Indeed, just covering the space of attacks on cryptographic protocols would be impractical. One might imagine that if there were a revision it would contain a paragraph or three on this topic, but nowhere near the 30-odd pages of material that is in this document, and I don't think it's independently a reason to do a 3552 revision. 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. -Ekr Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000cdd5860586d619db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 3:03 PM Ferna= ndo Gont <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>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Folks,
>
>=C2=A0 =C2=A0 =C2=A0At the last secdispatch meeting I presented our I-D=
>=C2=A0 =C2=A0 =C2=A0draft-gont-predictable-numeric-ids.
>
>=C2=A0 =C2=A0 =C2=A0>From the meeting discussion, it would seem to m= e that there is support
>=C2=A0 =C2=A0 =C2=A0for this work.
>
>=C2=A0 =C2=A0 =C2=A0It would also seem to me that part of this work is = to be pursued in an
>=C2=A0 =C2=A0 =C2=A0appropriate IRTF rg, while the update to RFC3552 >=C2=A0 =C2=A0 =C2=A0(draft-gont-numeric-ids-sec-considerations) should = be pursued as an
>=C2=A0 =C2=A0 =C2=A0AD-sponsored document.
>
>
> I'm somewhat skeptical on an update to 3552; the proposed set of t= hings
> to be improved seems unclear.

Can you please state what's unclear?

I understand the list of things in your document. However, there have bee= n proposals for a larger revision to 3552. The proposed set of such revisio= ns is unclear, and it's not clear to me why your document fits into suc= h a revision.

=C2=A0
> I don't think that the material in this document should be added t= o
> 3552, as the purpose of 3552 is not really to go into that kind of
> detail about any specific topic.

What I would expect is that RFC3552 helps prevent us from coming up with vulnerable implementations.

This is not the= purpose of 3552. Rather, it is to document what is required in a security = considerations section in general (the threat model, an overview of common = issues, etc.)=C2=A0 rather than to go into detail about a specific kind of = attack. Otherwise, the amount of detail would become impractical. Indeed, j= ust covering the space of attacks on cryptographic protocols would be impra= ctical. One might imagine that if there were a revision it would contain a = paragraph or three on this topic, but nowhere near the 30-odd pages of mate= rial that is in this document, and I don't think it's independently= a reason to do a 3552 revision.


That said, this document is *updating* RFC3552, rather than a revision
of RFC3552. Therefore, the content in this document wouldn't become par= t
of RFC3552, necessarily.

Well, the sema= ntics of "Updates" would be somewhat confusing here. Certainly I = don't think that this document is something we need to transitively inc= orporate 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.

-Ekr


Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000cdd5860586d619db-- From nobody Thu Apr 18 16:40:31 2019 Return-Path: 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 D49BE1201BA for ; Thu, 18 Apr 2019 16:40:21 -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, SPF_PASS=-0.001] autolearn=unavailable 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 3F5wYBhKecEA for ; Thu, 18 Apr 2019 16:40:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5541201B2 for ; Thu, 18 Apr 2019 16:40:18 -0700 (PDT) Received: from [192.168.3.138] (unknown [186.138.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5A22E8493B; Fri, 19 Apr 2019 01:40:10 +0200 (CEST) To: Eric Rescorla Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 01:39:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 23:40:22 -0000 On 19/4/19 01:09, Eric Rescorla wrote: > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > wrote: > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > >> 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. > > I don't think that the material in this document should be added to > > 3552, as the purpose of 3552 is not really to go into that kind of > > detail about any specific topic. > > What I would expect is that RFC3552 helps prevent us from coming up with > vulnerable implementations. > > > This is not the purpose of 3552. Rather, it is to document what is > required in a security considerations section in general (the threat > model, an overview of common issues, etc.)  rather than to go into > detail about a specific kind of attack. Otherwise, the amount of detail > would become impractical. Indeed, just covering the space of attacks on > cryptographic protocols would be impractical. One might imagine that if > there were a revision it would contain a paragraph or three on this > topic, but nowhere near the 30-odd pages of material that is in this > document, and I don't think it's independently a reason to do a 3552 > revision. You seem to be looking at the wrong document. The document in question is this one: https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations-03 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 ---- > 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. What we care about is to produce a change in what specifications do with respect to numeric ids, rather than that what specific document we are updating. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 18 17:02:06 2019 Return-Path: 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 2FE9B120248 for ; Thu, 18 Apr 2019 17:02:00 -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=unavailable 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 OdxFiuh8uOKz for ; Thu, 18 Apr 2019 17:01:58 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 C392A12004C for ; Thu, 18 Apr 2019 17:01:57 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id d12so2881169lfk.6 for ; 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=VMDld/iy4WU6fTapEs57qKYqoGm1S/TfC4q5A170x70k1z5up9NQcy5TDPeIgMAark guCIQRiZpPxEXx8KEn1X1DoODStGNQtH9KiMPfpBnmkO+T1rsgyXtZEJiRYxRPf9E3sG eN6uWk7dqeB52JTBdYgDXpANotIS6bAQPeSiYBoLCnK1JBBUkJ0cz/X0iwtd8qSKmM7j k4b1EnSyuOsrviDpvyvTYJgnsDPYmLOT775mUDa1VkE5vSQ1/3tfVIU0YtZsrba+3w5Y B8x2zBDRHkLcMsos0Wap4V6XW9NWQ8XXYIIWTm9b38pImwuLKYK4hLDQW3B188gF4qIu kTVw== X-Gm-Message-State: APjAAAUyLN2BHHMooTzWqC3u7GulBLZkLwutvzjuMPP7dKLcloOSO3Ot LjWrnff61ZhxUmbzKaKsq09kvcZ1CHNi9w/iTg5fQg== 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> In-Reply-To: From: Eric Rescorla Date: Thu, 18 Apr 2019 17:01:17 -0700 Message-ID: To: Fernando Gont Cc: =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000accd0e0586d6d31f" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 00:02:00 -0000 --000000000000accd0e0586d6d31f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont wrote: > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > wrote: > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > > > >> > 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 --000000000000accd0e0586d6d31f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 4:40 PM Ferna= ndo 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:
>
>=C2=A0 =C2=A0 =C2=A0On 18/4/19 15:45, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont<= br> >=C2=A0 =C2=A0 =C2=A0<fgont@si6networks.com <mailto:fgont@si6networks.com>
>=C2=A0 =C2=A0 =C2=A0> <mailto:fgont@si6networks.com <mailto:fgont@si6networks.com>&= gt;> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Folks,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0At the last secdispatch mee= ting I presented our I-D
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0draft-gont-predictable-nume= ric-ids.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>From the meeting discus= sion, it would seem to me that there
>=C2=A0 =C2=A0 =C2=A0is support
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0for this work.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0It would also seem to me th= at part of this work is to be
>=C2=A0 =C2=A0 =C2=A0pursued in an
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0appropriate IRTF rg, while = the update to RFC3552
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(draft-gont-numeric-ids-sec= -considerations) should be pursued
>=C2=A0 =C2=A0 =C2=A0as an
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0AD-sponsored document.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I'm somewhat skeptical on an update to 355= 2; the proposed set of
>=C2=A0 =C2=A0 =C2=A0things
>=C2=A0 =C2=A0 =C2=A0> to be improved seems unclear.
>
>=C2=A0 =C2=A0 =C2=A0Can you please state what's unclear?
>
>
> I understand the list of things in your document. However, there have<= br> > been proposals for a larger revision to 3552.

There was an effort to revise RFC3552. It just didn't happen. Looks lik= e
trying to boil the ocean wasn't the best idea.
Yes.

=C2=A0

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.=C2=A0 Security and Privacy Requirements for Identifiers

=C2=A0 =C2=A0Protocol specifications that specify transient numeric identif= iers
=C2=A0 =C2=A0MUST:

=C2=A0 =C2=A01.=C2=A0 Clearly specify the interoperability requirements for= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0aforementioned identifiers.

=C2=A0 =C2=A02.=C2=A0 Provide a security and privacy analysis of the aforem= entioned
=C2=A0 =C2=A0 =C2=A0 =C2=A0identifiers.

=C2=A0 =C2=A03.=C2=A0 Recommend an algorithm for generating the aforementio= ned
=C2=A0 =C2=A0 =C2=A0 =C2=A0identifiers that mitigates security and privacy = issues, such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0those discussed in [I-D.gont-predictable-numeric= -ids].
---- cut here ----

Eh, I think somethin= g like this would have been OK in 3552; I'm not
sure that it&= #39;s necessary to add at this point to the list of things that
3= 552 considers.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0That said, this document is *updating* RFC3552, rat= her than a revision
>=C2=A0 =C2=A0 =C2=A0of RFC3552. Therefore, the content in this document= wouldn't become part
>=C2=A0 =C2=A0 =C2=A0of 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 appro= ved)"
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 o= ne 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
--000000000000accd0e0586d6d31f-- From nobody Thu Apr 18 17:32:29 2019 Return-Path: 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 CF2491200C3 for ; Thu, 18 Apr 2019 17:32:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 BE6tpnb-ooc2 for ; Thu, 18 Apr 2019 17:32:18 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6801200FA for ; Thu, 18 Apr 2019 17:32:18 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6788380DC6; Fri, 19 Apr 2019 02:32:15 +0200 (CEST) To: Eric Rescorla Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 02:17:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 00:32:21 -0000 On 19/4/19 02:01, Eric Rescorla wrote: > > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont > wrote: > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > >> wrote: > > > >     On 18/4/19 15:45, Eric Rescorla wrote: > >     > > >     > > >     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > >      > > > >     > > >>> wrote: [....] > 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. Isn't https://tools.ietf.org/html/draft-gont-numeric-ids-history-04 enough of a justification to adding this? We keep producing specs with flawed IDs. Which take ages and a lot of effort an energy to fix. I'm kind of surprised that we're even discussing this. > >     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. We will not publish a new version of RFC3552 in the foreseeable future. That's a fact. So the issue you raise seems to boil down, in practice, whether we keep the "Updates: 3552 (if approved)" header and keep the two references to it (one in the abstract, and another in the Sec Cons). If that's the show-stopper, we don't mind removing that. The high-order bit here is to continue repeating the history of flawed IDs (there are active I-Ds that keep doing a bad job at this). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 18 18:25:16 2019 Return-Path: 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 To: Eric Rescorla Cc: Fernando Gont , pearg@irtf.org, IETF SecDispatch , =?iso-8859-1?Q?Iv=E1n_Arce_=28Quarkslab=29?= , secdispatch-chairs@ietf.org Message-ID: <20190419012507.GB95327@kduck.mit.edu> References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > wrote: > > > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > > > > > >> > > 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 From nobody Fri Apr 19 00:07:53 2019 Return-Path: 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 227B512017C for ; Fri, 19 Apr 2019 00:07:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 2NW7PN9N7_oO for ; Fri, 19 Apr 2019 00:07:48 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00053.outbound.protection.outlook.com [40.107.0.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF0A1202BB for ; Fri, 19 Apr 2019 00:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5KRDbnN9XVbXhrMn5vempWfD6gUIwpAHSAfbQNOc2HA=; b=fXs6ifg0NuFaqqKWFmTkGjN9dt8ldnbaEo3jkAU1ujxB7M6nvigIT4+DpYuc1Q3yogBt+5doxaHvF+3aFcH0OjiSaUgM45wBsXSN0467t4+rgAsG2m6LC87nCLSHPKZ04+W/dIiUgiG1R9XP13oVj1VMKosMHeEiiK4psDNY9mE= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4008.eurprd08.prod.outlook.com (20.179.0.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Fri, 19 Apr 2019 07:07:44 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Fri, 19 Apr 2019 07:07:44 +0000 From: Hannes Tschofenig To: Fernando Gont , Eric Rescorla CC: =?iso-8859-1?Q?Iv=E1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , "pearg@irtf.org" , "secdispatch-chairs@ietf.org" Thread-Topic: [Secdispatch] Numeric IDs: Update to RFC3552 Thread-Index: AQHU9DPSC6AaW/J3sUCYhloaFRIZ4KZB8XkAgACHeoCAAJgRgA== Date: Fri, 19 Apr 2019 07:07:44 +0000 Message-ID: References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ae77cc7-b501-401b-1751-08d6c495b8af x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4008; x-ms-traffictypediagnostic: AM6PR08MB4008: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(136003)(366004)(376002)(189003)(199004)(40434004)(13464003)(476003)(97736004)(4326008)(33656002)(74316002)(66066001)(2906002)(7736002)(25786009)(3846002)(8936002)(71200400001)(71190400001)(6116002)(52536014)(66476007)(68736007)(66556008)(72206003)(81166006)(305945005)(11346002)(446003)(14444005)(81156014)(486006)(5660300002)(478600001)(5024004)(966005)(6246003)(229853002)(55016002)(53936002)(186003)(26005)(66946007)(73956011)(99286004)(6306002)(6506007)(9686003)(102836004)(53546011)(316002)(8676002)(7696005)(76176011)(15650500001)(110136005)(14454004)(66574012)(256004)(6436002)(54906003)(86362001)(66446008)(64756008)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4008; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dzHy06BoeRa438QWwLVBjq0Mqp87B1NLJs+jW6Pa0pnqZL7iPsR7F9Yuxv9yZDkBp4z5BDKlDTJj7Kqp4JQok3ykQ5Slio7e2iQRo0bLn2qkQjuIFw9huumXH2eKoEqWe/Qo8CFjyKIcDZcnFz1ziq8xxfUTxC+AKOWe1I5A3eGd9SESishitcY9PaUT712McnTagjgjo7ZqGREPORZS03svbfzj+gfiuyD9bNZDSs2tAjnEMQSqZZim1hYWfAXx2I//37CvhwbXCez889WcOMyOmg7EGW9j+zLd+njNl5X1Hk3hHEPqD9T+Hg7cji8COfZT2JIsCYkKPLvdLbgNlvmOnJRbN38kky9R4uwv8pbKiyNpc84bw4CO42No3LmUeEapbdkTJqCfWNIVlPbCxOWixyWxtZKyOS9TMR9CNT0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ae77cc7-b501-401b-1751-08d6c495b8af X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 07:07:44.6146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4008 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 07:07:51 -0000 Hi Fernando, I am not sure why it is important for you to update RFC 3552. The argument = that it requires specification authors to consider your document in securit= y and privacy considerations is not IMHO not correct. If you document provides useful guidance then it should stand on its own. A few random comments from looking at it: - FWIW you should be re-using terms defined in RFC 6973, such as identifier= . - Why are you acknowledging yourself in your own draft? - You use the RFC 2119 term as requirements for protocol authors rather tha= n for interoperability. I think you should mention this in the terminology = section somewhere or not use RFC2119 language. - You should define somewhere what you consider a "transient numeric identi= fier". - In the introduction and in the abstract you describe a problem with imple= mentations (you refer to TCP) but the recommendations later aim for protoco= l authors. In many cases the authors of the specification and not the imple= menters. Do you believe that you have solved the problem? More comments will follow... Ciao Hannes -----Original Message----- From: Secdispatch On Behalf Of Fernando Gont Sent: Donnerstag, 18. April 2019 23:50 To: Eric Rescorla Cc: Iv=E1n Arce (Quarkslab) ; IETF SecDispatch ; pearg@irtf.org; secdispatch-chairs@ietf.org Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 On 18/4/19 15:45, Eric Rescorla wrote: > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > 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 suppo= rt > for this work. > > It would also seem to me that part of this work is to be pursued in a= n > 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? We have 30+ years of history of screwing up numeric identifiers in the prot= ocols we specify. Just to name a few: * TCP ISNs * TCP ephemeral ports * DNS TxIDs * IPv4 Frag IDs * IPv6 Frag IDs * IPv6 IIDs * NTP port numbers * NTP timestamps * TCP timestamps .... and the list can continue. We are trying, for once and for all, to act proactively in this respect, to= avoid repeating the same history in every protocol we specify, and every i= mplementation that comes up. > I don't think that the material in this document should be added to > 3552, as the purpose of 3552 is not really to go into that kind of > detail about any specific topic. What I would expect is that RFC3552 helps prevent us from coming up with vu= lnerable implementations. Clearly, the history of flawed IDs seems to indic= ate that we are doing something wrong. At the time of this writing, it seems that RFC3552 is the document that dra= ft/RFC authors are required to read when it comes to how to do a security a= nalysis of their document. So I am curious why you think this doesn't belon= g to RFC3552. That said, this document is *updating* RFC3552, rather than a revision of R= FC3552. Therefore, the content in this document wouldn't become part of RFC= 3552, necessarily. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Apr 19 02:05:27 2019 Return-Path: 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 9AC0B1200E0 for ; Fri, 19 Apr 2019 02:05:19 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zZncx_h_s3O2 for ; Fri, 19 Apr 2019 02:05:17 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30D412008F for ; Fri, 19 Apr 2019 02:05:16 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A0C8084A55; Fri, 19 Apr 2019 11:05:12 +0200 (CEST) To: Hannes Tschofenig , Eric Rescorla Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , "pearg@irtf.org" , "secdispatch-chairs@ietf.org" References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 11:03:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 09:05:20 -0000 On 19/4/19 09:07, Hannes Tschofenig wrote: > Hi Fernando, > > I am not sure why it is important for you to update RFC 3552. So that folks are required to do the corresponding analysis of numeric I-Ds as part of the security considerations section? FWIW, I think that's the *right* thing to do. That said, at this point, I can live without that, if that's the "showstopper". > The > argument that it requires specification authors to consider your > document in security and privacy considerations is not IMHO not > correct. If you document provides useful guidance then it should > stand on its own. Again, while I do think the right thing is to update RFC3552, I'm not planning to spend a lot of Joules fighting this point. > A few random comments from looking at it: > > - FWIW you should be re-using terms defined in RFC 6973, such as > identifier. Will check. Thanks for the pointer. > - Why are you acknowledging yourself in your own draft? - We're just noting that this document is a spin off of gont-predictable-numeric-ids, because: 1) We cannot predict the faith of the other pieces 2) The folks we credit didn't provide feedback on this particular doc, but on the larger document. Not crediting them would be unfair. Claiming that they provided feedback on *this* document would be incorrect/not-true. > You use the RFC 2119 term as requirements for protocol authors rather > than for interoperability. I think you should mention this in the > terminology section somewhere or not use RFC2119 language. Point taken. Will address this. Thanks! > - You > should define somewhere what you consider a "transient numeric > identifier". - In the introduction and in the abstract you describe a > problem with implementations (you refer to TCP) but the > recommendations later aim for protocol authors. In many cases the > authors of the specification and not the implementers. Do you believe > that you have solved the problem? Please see section 3: most of the times there are problems in the implementations is because the advice in the specs is flawed, or because the requirements are underspecified -- and hence the implementors have no option other than figuring out things by themselves. I can't think of a case of IDs where the specs did the right thing and the implementors screwed up. > More comments will follow... Look forward to them! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 19 02:15:49 2019 Return-Path: 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 D245D1200E0 for ; Fri, 19 Apr 2019 02:15:47 -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, 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 CEGyM0D40dXF for ; Fri, 19 Apr 2019 02:15:46 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA21120044 for ; Fri, 19 Apr 2019 02:15:45 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8B2438457A; Fri, 19 Apr 2019 11:15:40 +0200 (CEST) To: Hannes Tschofenig , Eric Rescorla Cc: "pearg@irtf.org" , IETF SecDispatch , =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , "secdispatch-chairs@ietf.org" References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 11:15:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 09:15:48 -0000 On 19/4/19 09:07, Hannes Tschofenig wrote: > Hi Fernando, > > I am not sure why it is important for you to update RFC 3552. The argument that it requires specification authors to consider your document in security and privacy considerations is not IMHO not correct. > If you document provides useful guidance then it should stand on its own. > > A few random comments from looking at it: > > - FWIW you should be re-using terms defined in RFC 6973, such as identifier. > - Why are you acknowledging yourself in your own draft? > - You use the RFC 2119 term as requirements for protocol authors rather than for interoperability. I think you should mention this in the terminology section somewhere or not use RFC2119 language. As an example: If you look at the requirements for ephemeral ports in RFC793 or RFC768, they are underspecified -- only the interoperability requirements are specified, and the implementer has to figure out the algorithm himself/herself. --- RFC6056 complements that. OTOH, the IPv6 Fragment ID generation in RFC2460 is overspecified: a global counter is suggested, leading to predictable Frag IDs, unnecessarily. IN both cases, there were implementations with predictable port numbers and predictable IPv6 Frag IDs. In the former case, because doing incremental port numbers was an easy way to comply with the*interoperability* requirements -- and the spec doesn't consider the predictability aspec. In the later case, the spec itself suggests an inappropriate IPv6 Frag ID generation algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 19 07:47:58 2019 Return-Path: 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 D5C6D120159 for ; Fri, 19 Apr 2019 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 RH4noTCeNovK for ; Fri, 19 Apr 2019 07:47:50 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 5C6751202E4 for ; Fri, 19 Apr 2019 07:47:47 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id p14so4872707ljg.5 for ; Fri, 19 Apr 2019 07:47:47 -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=ncKEyVHeVOiesfYYk73ytfIB1Si52lC5VYv63SnAKAY=; b=aZL7w3hXwKRC6khfWsypFcncU67PL8pCdmKQcoL5HS3RFtucHMCXuw71lRGsvIpRQq 88N1c4TeagVLvylrNMZumY1D3n+j0jHITvg9n32CEQKTZbdGYPnyrGLiKwvaPz+YaqRW jAO5E3FKcqBQeGVOF5wKg4r6APvOG3QjvuIRbHWnzXCW6gSj4OIv4le9r71KODQfjasc ULdvoHC5N2ZqWjCiJWMtjS6OmrRyCo4+64uAQLIQcEf4oqzas/MWZYHCIS82qV2xsOB6 bIme2lH/o0sS+izaRkha970FudzwiWaGlw76lopp0r4OCPiqq5mnyATAFVMq0gvojbXD m9PA== 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=ncKEyVHeVOiesfYYk73ytfIB1Si52lC5VYv63SnAKAY=; b=ZLlG1ts6VTiehwtAbmxx2JTu0wa1enUlzlPl3jsBEvTOPyoo3v8Rfgl9SoIiPSJKIg HXryEHP/nSIQJJ3MMxwVp0NArF96Hd7m2nXEZWCQW7V7vs07ZTHR5H6leaVc5m3FKyOX 3sr2J6gqT10sqvGSQu+E7HMsRvTYdWHmvEaSNwrENHJ7VxpAk0C2pmjR4rCYs7efvdAK Sxhd5YP8GwTAeIMiZNq5I5BTDAqa6JKKorvE2taLy6PxzUqDumQ1Zcqhr8dvWdiiK16c vzv5jl+3u57uR8HnnXjXupZI6U8IKGwbkL+TXLS7s75Z1pvowscS1uMY9U8VlCpgBO49 8T+g== X-Gm-Message-State: APjAAAWPszNBXjRfw8qr3br7Pg4ROSmie9EAq59zdtegWmn2illIFzCU 230/PJdz35OYDgZlZfellBVIkTYrUsNQKmmsu+wcrA== X-Google-Smtp-Source: APXvYqzybPfoKyQQEU4eO1jdERF9iOOv87keKd33kz5nC2rzwzlbNxwIiWmh1Zh1pqdXGoiU1slSCYwtSyi9yvB8eVM= X-Received: by 2002:a2e:9194:: with SMTP id f20mr2561166ljg.10.1555685265516; Fri, 19 Apr 2019 07:47:45 -0700 (PDT) MIME-Version: 1.0 References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> <20190419012507.GB95327@kduck.mit.edu> In-Reply-To: <20190419012507.GB95327@kduck.mit.edu> From: Eric Rescorla Date: Fri, 19 Apr 2019 07:47:07 -0700 Message-ID: To: Benjamin Kaduk Cc: Fernando Gont , IETF SecDispatch , pearg@irtf.org, =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= , secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a259630586e333da" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 14:47:52 -0000 --000000000000a259630586e333da Content-Type: text/plain; charset="UTF-8" On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk wrote: > On Thu, Apr 18, 2019 at 05:01:17PM -0700, Eric Rescorla wrote: > > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont > wrote: > > > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > > wrote: > > > > > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > > > > > > > >> > > > 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)? > I don't really think either of them matters much one way or the other. -Ekr > Thanks, > > Ben > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --000000000000a259630586e333da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 6:25 PM Benja= min Kaduk <kaduk@mit.edu> wrote:=
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<= br> > > > <mailto:fgont@si6networks.com>> wrote:
> > >
> > >=C2=A0 =C2=A0 =C2=A0On 18/4/19 15:45, Eric Rescorla wrote: > > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0> On Tue, Apr 16, 2019 at 2:07 AM Fern= ando Gont
> > >=C2=A0 =C2=A0 =C2=A0<fgont@si6networks.com <mailto:fgont@si6networks.com> > > >=C2=A0 =C2=A0 =C2=A0> <mailto:fgont@si6networks.com <mailto:fgont@si6networks.co= m>>>
> > wrote:
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Folks,
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0At the last secdi= spatch meeting I presented our I-D
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0draft-gont-predic= table-numeric-ids.
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>From the meet= ing discussion, it would seem to me that there
> > >=C2=A0 =C2=A0 =C2=A0is support
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0for this work. > > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0It would also see= m to me that part of this work is to be
> > >=C2=A0 =C2=A0 =C2=A0pursued in an
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0appropriate IRTF = rg, while the update to RFC3552
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(draft-gont-numer= ic-ids-sec-considerations) should be pursued
> > >=C2=A0 =C2=A0 =C2=A0as an
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0AD-sponsored docu= ment.
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0> I'm somewhat skeptical on an upd= ate to 3552; the proposed set of
> > >=C2=A0 =C2=A0 =C2=A0things
> > >=C2=A0 =C2=A0 =C2=A0> to be improved seems unclear.
> > >
> > >=C2=A0 =C2=A0 =C2=A0Can you please state what's unclear?<= br> > > >
> > >
> > > I understand the list of things in your document. However, t= here 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.=C2=A0 Security and Privacy Requirements for Identifiers
> >
> >=C2=A0 =C2=A0 Protocol specifications that specify transient numer= ic identifiers
> >=C2=A0 =C2=A0 MUST:
> >
> >=C2=A0 =C2=A0 1.=C2=A0 Clearly specify the interoperability requir= ements for the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 aforementioned identifiers.
> >
> >=C2=A0 =C2=A0 2.=C2=A0 Provide a security and privacy analysis of = the aforementioned
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 identifiers.
> >
> >=C2=A0 =C2=A0 3.=C2=A0 Recommend an algorithm for generating the a= forementioned
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 identifiers that mitigates security an= d privacy issues, such as
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 those discussed in [I-D.gont-predictab= le-numeric-ids].
> > ---- cut here ----
> >
>
> Eh, I think something like this would have been OK in 3552; I'm no= t
> sure that it's necessary to add at this point to the list of thing= s that
> 3552 considers.
>
>
>
> > >=C2=A0 =C2=A0 =C2=A0That said, this document is *updating* RF= C3552, rather than a
> > revision
> > >=C2=A0 =C2=A0 =C2=A0of RFC3552. Therefore, the content in thi= s document wouldn't become
> > part
> > >=C2=A0 =C2=A0 =C2=A0of 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 ab= out 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 RFC= 3552"),
> > please say so.
>
>
> No, that's not my point. As I said, I don't think we should pu= blish 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 additio= nal
document in BCP 72 (vs. both or none)?

= I don't really think either of them matters much one way or the other.<= /div>

-Ekr


Thanks,

Ben

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--000000000000a259630586e333da-- From nobody Sat Apr 20 10:56:59 2019 Return-Path: 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 598F6120186 for ; Sat, 20 Apr 2019 10:56:58 -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, SPF_PASS=-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 9d80qWt1QD4T for ; Sat, 20 Apr 2019 10:56:55 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD573120162 for ; Sat, 20 Apr 2019 10:56:54 -0700 (PDT) Received: from [192.168.0.148] (unknown [88.247.88.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4D40C84BC0; Sat, 20 Apr 2019 19:56:39 +0200 (CEST) To: Eric Rescorla , Benjamin Kaduk Cc: IETF SecDispatch , pearg@irtf.org, =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , secdispatch-chairs@ietf.org References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> <20190419012507.GB95327@kduck.mit.edu> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <32c21255-5840-529e-4f6d-4d65966d88d4@si6networks.com> Date: Sat, 20 Apr 2019 19:48:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 17:56:59 -0000 On 19/4/19 16:47, Eric Rescorla wrote: > > > On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk > wrote: > > On Thu, Apr 18, 2019 at 05:01:17PM -0700, Eric Rescorla wrote: > > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont > > wrote: > > > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > > > >> > wrote: > > > > > > > >     On 18/4/19 15:45, Eric Rescorla wrote: > > > >     > > > > >     > > > > >     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > >      > > > > > >     > >>> > > > 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)? FWIW, our take is that by formally updating rfc3552 protocol specs would be forced to do the write thing, numeric identifiers would be subject to the right analysis, and the security considerations would need to include a security/privacy assessment of any numeric identifiers employed/specified in the corresponding spec. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492