Re: [Pearg] [Secdispatch] Numeric IDs: Update to RFC3552

[Fernando Gont <[e-mail]>]

On 19/4/19 02:01, Eric Rescorla wrote:
> 
> On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On 19/4/19 01:09, Eric Rescorla wrote:
>     >
>     >
>     > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >     On 18/4/19 15:45, Eric Rescorla wrote:
>     >     >
>     >     >
>     >     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont
>     >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     > <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> 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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492