Re: [Secdispatch] Numeric IDs: Update to RFC3552

On Thu, Apr 18, 2019 at 3:03 PM Fernando 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:
> >
> >     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
>