Re: [Secdispatch] Numeric IDs: Update to RFC3552

[Fernando Gont <[e-mail]>]

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]>> 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]>>> 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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492