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

[Hannes Tschofenig <[e-mail]>]

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.
- 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?

More comments will follow...

Ciao
Hannes


-----Original Message-----
From: Secdispatch <[e-mail]> On Behalf Of Fernando Gont
Sent: Donnerstag, 18. April 2019 23:50
To: Eric Rescorla <[e-mail]>
Cc: Iván Arce (Quarkslab) <[e-mail]>; IETF SecDispatch <[e-mail]>; [e-mail]; [e-mail]
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 <[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?

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




_______________________________________________
Secdispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdispatch
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.