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

[Fernando Gont <[e-mail]>]

On 19/4/19 16:47, Eric Rescorla wrote:
> 
> 
> On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk <[e-mail]
> <mailto:[e-mail]>> 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
>     <[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:
>     > > >     >
>     > > >     >     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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492