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

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Apr 2019 23:50:03 +0200

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Apr 2019 16:09:19 -0700

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

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

> of RFC3552. Therefore, the content in this document wouldn't become part

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,
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Apr 2019 01:39:56 +0200

On 19/4/19 01:09, Eric Rescorla wrote:
> 
> 
> On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont <[email-masked]
>     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Folks,
>     >
>     >     >From the meeting discussion, it would seem to me that there
>     is support
>     >     for this work.
>     >
> 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.

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

> 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,

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Apr 2019 17:01:17 -0700

> trying to boil the ocean wasn't the best idea.

Yes.

>        those discussed in [I-D.gont-predictable-numeric-ids].

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.

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

-Ekr

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Apr 2019 02:17:01 +0200

On 19/4/19 02:01, Eric Rescorla wrote:
> 
> On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont <[email-masked]
>     > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont
>     >     >
>     >     >
>     >     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
[....]
> sure that it's necessary to add at this point to the list of things that

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.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Apr 2019 20:25:07 -0500

> it as updating 3552 is that helpful, I'm not going to die on that hill

Do you care to state an opinion on "Updates: 3552" vs. an additional
document in BCP 72 (vs. both or none)?

Thanks,

Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 Apr 2019 07:07:44 +0000

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 <[email-masked]> On Behalf Of Fernando Gont
Sent: Donnerstag, 18. April 2019 23:50
To: Eric Rescorla <[email-masked]>
Cc: Iván Arce (Quarkslab) <[email-masked]>; IETF SecDispatch <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552

On 18/4/19 15:45, Eric Rescorla wrote:
> I'm somewhat skeptical on an update to 3552; the proposed set of
> things to be improved seems 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.

> 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,

_______________________________________________
Secdispatch mailing list
[email-masked]
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.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Apr 2019 11:03:29 +0200

On 19/4/19 09:07, Hannes Tschofenig wrote:
> Hi Fernando,
> 
> I am not sure why it is important for you to update RFC 3552.

So that folks are required to do the corresponding analysis of numeric
I-Ds as part of the security considerations section?

FWIW, I think that's the *right* thing to do. That said, at this point,
I can live without that, if that's the "showstopper".

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

Again, while I do think the right thing is to update RFC3552, I'm not
planning to spend a lot of Joules fighting this point.

> - FWIW you should be re-using terms defined in RFC 6973, such as

Will check. Thanks for the pointer.

> - Why are you acknowledging yourself in your own draft? -

We're just noting that this document is a spin off of
gont-predictable-numeric-ids, because:

1) We cannot predict the faith of the other pieces

2) The folks we credit didn't provide feedback on this particular doc,
but on the larger document. Not crediting them would be unfair. Claiming
that they provided feedback on *this* document would be incorrect/not-true.

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

Point taken. Will address this. Thanks!

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

Please see section 3: most of the times there are problems in the
implementations is because the advice in the specs is flawed, or because
the requirements are underspecified -- and hence the implementors have
no option other than figuring out things by themselves.

I can't think of a case of IDs where the specs did the right thing and
the implementors screwed up.

> More comments will follow...

Look forward to them!

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Apr 2019 11:15:34 +0200

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

As an example:

If you look at the requirements for ephemeral ports in RFC793 or RFC768,
they are underspecified -- only the interoperability requirements are
specified, and the implementer has to figure out the algorithm
himself/herself. --- RFC6056 complements that.

OTOH, the IPv6 Fragment ID generation in RFC2460 is overspecified: a
global counter is suggested, leading to predictable Frag IDs, unnecessarily.

IN both cases, there were implementations with predictable port numbers
and predictable IPv6 Frag IDs.

In the former case, because doing incremental port numbers was an easy
way to comply with the*interoperability* requirements -- and the spec
doesn't consider the predictability aspec.

In the later case, the spec itself suggests an inappropriate IPv6 Frag
ID generation algorithm.

Thanks,

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Apr 2019 07:47:07 -0700

On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk <[email-masked]> wrote:

> > > >     >     >From the meeting discussion, it would seem to me that
> there
> > > >     is support
> > > >     >     for this work.
> > > >     >
> > > >     >     (draft-gont-numeric-ids-sec-considerations) should be
> pursued
> > > >     as an
> > > >     >     AD-sponsored document.
> > > >     >
> > > >     >
> > > >     of RFC3552. Therefore, the content in this document wouldn't
> become
> > > part
> > > >     of RFC3552, necessarily.
> > > >
> > > >

I don't really think either of them matters much one way or the other.

-Ekr

> Thanks,
>
> Ben
>
> --
> Pearg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/pearg
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 Apr 2019 19:48:50 +0200

On 19/4/19 16:47, Eric Rescorla wrote:
> 
> 
> On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > > >     > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>     > > 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.
>     > > >
>     > > >     of RFC3552. Therefore, the content in this document
>     wouldn't become
>     > > part
>     > > >     of RFC3552, necessarily.
>     > > >
>     > > >

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,