Subject: [saag] Fwd: AD evaluation of draft-gont-numeric-ids-sec-considerations-04

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Jul 2020 21:13:38 -0700

Forwarding my review comments to SAAG since I forgot to put it in the
original email...

-Ben

On Fri, Jul 17, 2020 at 01:46:08PM -0700, Benjamin Kaduk wrote:
> Hi Fernando, Ivan,
> 
> While this is nominally just a single AD's evaluation of the document, I
> find that the general tone and structure are not a great match for what
> I was expecting, given the secdispatch session several IETFs ago.
> (Shame on me for taking so long to do the review, yes.)  I don't want to
> be imposing my own preferences on what should really be a community
> document, though, so I'm copying my comments to the SAAG list as well,
> to get broader feedback and ensure that I can be reined in when I'm
> getting too far from the consensus position.
> 
> I have several points that seem particularly important or potentially
> contentious; however, because they will make more sense in the context
> of the rest of the document, I am leaving them embedded in the inline
> comments, and will mark them with "[*]".
> 
> Abstract
> 
>    For more than 30 years, a large number of implementations of the TCP/
>    IP protocol suite have been subject to a variety of attacks, with
>    effects ranging from Denial of Service (DoS) or data injection, to
>    information leakage that could be exploited for pervasive monitoring.
> 
> This much historical background is probably overkill for an Abstract.
> 
>    The root of these issues has been, in many cases, the poor selection
>    of transient numeric identifiers in such protocols, usually as a
>    result of insufficient or misleading specifications.  This document
>    formally updates RFC3552, such that RFCs are required to include a
>    security and privacy analysis of the transient numeric identifiers
>    they specify.
> 
> I might reformulate the whole thing as something more like:
> 
> % Poor selection of transient numerical identifiers in protocols such as
> % the TCP/IP suite has historically led to a number of attacks on
> % implementations, ranging from Denial of Service (DoS) to data
> % injection and information leakage that can be exploited by pervasive
> % monitoring.  To prevent such flaws in future protocols and
> % implementations, this document updates RFC 3552, requiring future RFCs
> % to contain analysis of the security and privacy properties of any
> % transient numeric identifiers specified by the protocol.
> 
> Section 1
> 
>    Interface Identifiers (IIDs).  These identifiers usually have
>    specific properties that must be satisfied such that they do not
>    result in negative interoperability implications (e.g. uniqueness
>    during a specified period of time), and an associated failure
> 
> nit: comma after "e.g.".
> 
>    For more than 30 years, a large number of implementations of the TCP/
>    IP protocol suite have been subject to a variety of attacks, with
> 
> (editorial) the transition from the previous paragraph might flow better
> if this was something like "The TCP/IP protocol suite alone has been
> subject to variety of attacks on its numerical identifiers over the past
> 30 years or more, with [...]".
> 
>    o  Predictable DNS TxIDs
> 
> [DNS TxIDs are pretty hard to argue for being part of the "TCP/IP
> protocol suite", so I added a hedge word "alone" in my previous
> suggestion]
> 
> Section 2
> 
> What's wrong with the RFC 4949 definition of "identifier"?
> (We'd still want to keep the discussion about "transient", of course.)
> 
> Also, we should pick up the new BCP 14 boilerplate from RFC 8174.
> 
> Section 3
> 
> [*] Overall, I find this section longer than I expected, spending "too
> much time" on examples and evangelizing.  I have some specific comments
> below, but I'm not sure that just addressing the specific comments would
> change the overall impression that the section gives.
> 
>    While assessing protocol specifications and implementations regarding
>    the use of transient numeric identifiers
>    [I-D.gont-numeric-ids-history], we found that most of the issues
>    discussed in this document arise as a result of one of the following
>    conditions:
> 
> (editorial) A potential rewording that hews closer to "typical RFC
> style" might be:
> 
> % A recent survey of transient numerical identifier usage in protocol
> % specifications and implementations [I-D.gont-numeric-ids-history]
> % revealed that most of the issues discussed in this document arise as a
> % result of one of the following conditions:
> 
>    A number of protocol implementations (too many of them) simply
>    overlook the security and privacy implications of identifiers.
>    Examples of them are the specification of TCP port numbers in
>    [...]
>    On the other hand, there are a number of protocol specifications that
>    over-specify some of their associated protocol identifiers.  For
>    example, [RFC4291] essentially results in link-layer addresses being
>    embedded in the IPv6 Interface Identifiers (IIDs) when the
>    [...]
> 
> I wonder if the writing would be tighter if we diverged from the "one
> bullet point, one paragraph" style.  Consider:
> 
> % Both under-specifying and over-specifying identifier contents is
> % hazardous.  TCP port numbers and sequence numbers [RFC0793] and DNS
> % TxID [RFC1035] were under-specified, leading to implementations that
> % used predictable values and thus were vulnerable to numberous off-path
> % attacks.  Over-specification, as for IPv6 Interface Identifiers (IIDs)
> % [RFC4291] and Fragment Identification values [RFC2460], leaves
> % implementations unable to respond to security and privacy issues
> % stemming from the mandated algorithm -- IPv6 IIDs need not expose
> % privacy-sensitive link-layer addresses, and predictable Fragment
> % Identifiers invite the same off-path attacks that plague TCP.
> 
>    Finally, there are protocol implementations that simply fail to
>    comply with existing protocol specifications.  For example, some
>    popular operating systems (notably Microsoft Windows) still fails to
>    implement transport-protocol port randomization, as specified in
>    [RFC6056].
> 
> It's not clear that this chunk speaks to the third bullet point; from
> the IETF perspective, implementation of ("compliance with") our
> protocols is optional, and there's not a lever in place to force people
> to take updates when we revise/update the spec.  Implementing only part
> of a spec is a problem, but if we want to lament lack of adoption of
> follow-on updates, we should be writing things differently.
> 
>    By requiring protocol specifications to clearly specify the
>    interoperability requirements for the transient numeric identifiers
>    they specify, the constraints in the possible algorithms to generate
>    them, as well as possible over-specification of such identifiers,
>    become evident.  Furthermore, requiring specifications to include a
> 
> nit(?): I'm not sure whether "constraints" is the right word here --
> what is being constrained, and by whom?  Would "limitations" or "risks"
> be workable?
> 
>    security and privacy analysis of the transient numeric identifiers
>    they specify prevents the corresponding considerations from being
>    overlooked at the time a protocol is specified.
> 
> [*] I really don't think this is an appropriate way to phrase what we're
> doing.  To specifically *require* authors to include an analysis that
> covers these particular points seems to be quite a divergence from RFC
> 3552 -- while the presence of a security considerations section in RFCs
> is required, what RFC 3552 claims to provide is just guidelines for how
> to write such a section.  Isn't what we're doing here just an
> incremental addition to that guidance, not a new hard requirement on
> authors?
> 
> Section 4
> 
> [*] Similarly to Section 3, this section felt significantly longer than
> I was expecting.  Could you say something about the motivation for
> putting content here as opposed to (e.g.)
> draft-irtf-pearg-numeric-ids-generation?  (Note, this section currently
> references draft-gont-predictable-numeric-ids, which is IIRC the
> pre-split consolidated document.)
> 
> [The list itself is good; no complaints about that.]
> 
> Adherence to the one-paragraph-follow-up-per-bullet-point style may be
> at the crux of the matter, here, too.  Perhaps we could just slightly
> expand the elements of the list itself and avoid having large chunks of
> text after it entirely.
> 
>    When one identifier is employed across contexts where such constancy
>    is not needed, activity correlation is made made possible.  For
>    example, [RFC4291] essentially results in link-layer addresses being
>    embedded in the IPv6 Interface Identifiers (IIDs) when the
>    interoperability requirement of uniqueness could be achieved in other
> 
> (We mentioned the IID+link-layer address before; it's a bit hard for me
> to justify having discussion about it in two places in this document.)
> 
>    Re-using identifiers across different layers or protocols ties the
>    security and privacy of the protocol re-using the identifier to the
>    security and privacy properties of the original identifier (over
>    which the protocol re-using the identifier may have no control
>    regarding its generation).  Besides, when re-using an identifier
> 
> It's also probably worth noting that this makes the privacy (and, to
> some extent, security) analysis harder, since you can no longer just
> consider each protoco in isolation and instead have to look at the
> combined system.
> 
> Section 5
> 
> [*] This seems like the meat of the document, but it's at risk of
> getting lost due to the size of Sections 3 and 4.  Perhaps the
> Introduction should specifically say something like "the key guidelines
> for protocol designers are found in Section 5" to call it out.
> 
>    Protocol specifications that specify transient numeric identifiers
>    MUST:
> 
> [*] This gets into the same question as above about "RFC 3552 doesn't
> require specific things in the security considerations; why should we?".
> I think we should rephrase this, perhaps:
> 
> % When a protocol specifies transient numerical identifiers, it is
> % critical for the security and privacy considerations to include
> % anlysis that:
> 
> (with the corresponding verb tense changes for the list itself).
> 
>    1.  Clearly specify the interoperability requirements for the
>        aforementioned identifiers.
> 
> Hmm, would it be fair to say "interoperability (i.e., functional)"?
> 
>    2.  Provide a security and privacy analysis of the aforementioned
>        identifiers.
> 
> This one is perhaps redundant with the revised lead-in, though.
> 
> Section 7
> 
>    This entire document is about the security and privacy implications
>    of transient numeric identifiers, and formally updates [RFC3552] such
>    that the "Security Considerations" sections of RFCs are required to
> 
> [if the other changes go through, the "required" wording will need to be
> tweaked]
> 
> Section 9.1
> 
> We seem to only be using RFCs 793, 2460, 6056, and 8200 as examples, so
> they would be okay to relegate to the Informative References section.
> 
> Section 9.2
> 
> Keeping [I-D.gont-predictable-numeric-ids] around for the
> Acknowledgments makes sense, but (as noted above) we should refer to the
> appropriate post-split document(s) in the main body text.
> 
> Section 9.3
> 
> Please consolidate into Section 9.2
> 
> 
> Thanks,
> 
> Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Jul 2020 22:43:37 -0700

And here's Fernando's responses and my follow-ups.
Sorry again for not getting this right the first time.

-Ben

On Mon, Jul 20, 2020 at 08:39:38PM -0700, Benjamin Kaduk wrote:
> Hi Fernando,
> 
> Oops, it looks like I failed to actually cc: SAAG on my initial comments
> like I had planned to.  [...]
> 
> On Fri, Jul 17, 2020 at 10:41:02PM -0300, Fernando Gont wrote:
> > Hello, Benjamin,
> > 
> > On 17/7/20 17:46, Benjamin Kaduk wrote:
> > [....]
> > > 
> > > Abstract
> > > 
> > I agree. We probably kept the Abstract from the time the whole project 
> > was a single document, so your suggestion makes perfect sense.
> > 
> > 
> > Unless there are objections, I'll apply your suggested change verbatim. 
> > Thanks!
> > 
> > 
> > 
> > > Section 1
> > > 
> > Well, the DNS is the Internet's directory service, so to speak. But your 
> > suggestion is fine, so I'll apply it.
> > 
> > 
> > 
> > > Section 2
> > > 
> > To be honest, we missed there was this definition of "identifier" in the 
> > RFC series. That said, the definition in RFC4949 also acommodates 
> > non-numeric identifiers, for which the concept of e.g. "linear" , 
> > monotonically-increasing, etc. would not apply.
> 
> This is true (and I was not sure whether pulling in 4949 for a single
> definition was going to help much -- it doesn't cover any of the other
> things we need).
> 
> > I would suggest that we replace this definition of "identifier" with the 
> > definition of "transient numeric identifier", which is the specific 
> > identifiers we're concerned with here. 
> 
> That seems like a really good approach (especially since we explicitly say
> we will use the shorter term to refer to the same thing in this document).
> 
> > draft-irtf-pearg-numeric-ids-history defines them as:
> > 
> >     Transient Numeric Identifier:
> >        A data object in a protocol specification that can be used to
> >        definitely distinguish a protocol object (a datagram, network
> >        interface, transport protocol endpoint, session, etc) from all
> >        other objects of the same type, in a given context.  Transient
> 
> This "in a given context" seems to be the only text at present that touches
> on the "transient" part.  That may well be fine; all the ideas that are
> coming to me about "the contest in which the identifier is valid is limited
> in scope or time, e.g., a connection lifetime or replay timer" or similar
> feel like they are probably too much detail.
> 
> >        numeric identifiers are usually defined as a series of bits, and
> >        represented using integer values.  These identifiers are typically
> >        dynamically selected, as opposed to statically-assigned numeric
> >        identifiers (see e.g.  [IANA-PROT]).  We note that different
> >        identifiers may have additional requirements or properties
> >        depending on their specific use in a protocol.  We use the term
> >        "transient numeric identifier" (or simply "numeric identifier" or
> >        "identifier" as short forms) as a generic term to refer to any
> >        data object in a protocol specification that satisfies the
> >        identification property stated above.
> > 
> > 
> > 
> > 
> > Definitely. Will do.
> > > much time" on examples and evangelizing. 
> > 
> > FWIW, we might keep the bullets in this section, and simply, right after 
> > the bullets, refer to draft-irtf-pearg-numeric-ids-history and 
> > draft-irtf-pearg-numeric-ids-generation for further details. Thoughts?
> 
> That would probably work.  I think it would be okay to have maybe another
> sentence for each bullet, too, but let's see what it looks like.
> > 
> > 
> > > I have some specific comments
> > FWIW, what we tried to do here was to provide one example regording what 
> > we meant by "under-specification" (the requirements are to clearly 
> > spelled out), "over-specification" (a proposed algorithm overloads the 
> > ID with properties it need not have), etc., such future specs avoid 
> > incurring into the same error.
> 
> (thanks for making it clear)
> 
> > > to take updates when we revise/update the spec.  
> > 
> > Agreed. What we meant by this bullet is that there are cases where the 
> > specs do the right thing, but there's a flaw in how the spec is turned 
> > into an implementation. (or well, the spec wasn't implemented at all).
> > 
> > 
> > 
> > > Implementing only part
> > What we meant here is that this is a case where you might face security 
> > issues arising from flawed transient numeric IDs, but this has nothing 
> > to do with suboptimal specs, but rather with suboptimal implementations 
> > (and in that sense there's not much we (IETF) can do about them).
> 
> Sure.  "The right thing to do is properly specified (whether in a given
> document or an update to it), but the implementation just didn't do the
> right thing."
> 
> > 
> > > 
> > Probably an issue of "English as second language" here, sorry: I guess 
> > we could have used "requirements" instead of "constraints". i.e., what 
> > we meant is that if you spell out the interoperability requirements, two 
> > things will become evident:
> > 
> > 1) The very "function" the algorithm needs to implement (e.g. if you 
> > need monotonically-increasing IDs, you better make sure that a new 
> > transient ID is larger than its predecesario), and,
> > 
> > 2) It would become evident when you are overspecifying things (.e.g, 
> > monotonically-increasing IDs need not be a global counter that starts at 
> > 0 -- that's not necessary to achieve monotonically-increasing IDs).
> 
> Thanks for writing this out, it helps a lot.  I suspect that what we
> actually want is to keep "constraints", but s/in/on/ -- the "constraints on
> the possible algorithms" are exactly the "function the algorithm needs to
> implement", which leads nicely into the "possible over-specification" that
> matches your point (2).
> 
> > 
> > 
> > Indeed.
> > How about changing the paragraph to:
> > 
> >     Clear specification of the interoperability requirements for the
> >     transient numeric identifiers will help identify possible algorithms
> >     that could be employed to generate them, and also make evident
> >     if such identifiers are being over-specify. A protocol specification
> 
> ("over-specified")
> 
> >     will usually also benefit from a security and privacy analysis of
> >     the transient numeric identifiers they specify, to prevents the
> 
> ("to prevent")
> 
> >     corresponding considerations from being overlooked in the protocol
> >     specification itself.
> > 
> > ?
> 
> Looks good; just the indicated nits.
> 
> > 
> > 
> > > Section 4
> > > 
> > We were not sure if sentences such as "Employing the same identifier 
> > across contexts in which constancy is not required" or "Employing the 
> > same increment space across different contexts" would make sense to the 
> > reader without any context.
> > 
> > I can think of two options to address your comment:
> > 1) Keep the list, and point to draft-irtf-pearg-numeric-ids-generation 
> > right after that.
> > 
> > 2) Strip much of the contents of this section (notably the specific 
> > examples) as follows:
> > 
> > ---- cut here ----
> >     Employing trivial algorithms for generating the identifiers means
> >     that any node that is able to sample such identifiers can easily
> >     predict future identifiers employed by the victim node.
> > 
> >     example, employing an identifier that is constant across networks
> >     allows for node tracking across networks.
> > 
> >     across protocols from different layers, the goal of of isolating the
> >     properties of a layer from that of another layer is broken, and the
> >     privacy and security analysis may be harder to perform, since the
> >     combined system, rather than each protocol in isolation will have to
> >     be assessed.
> 
> I see I made this one longer, but I don't get to complain :)
> 
> >     At times, a protocol needs to convey order information (whether
> >     sequence, timing, etc.).  In many cases, there is no reason for the
> >     corresponding counter or timer to be initialized to any specific
> >     value e.g. at system bootstrap.
> 
> (Unrelated to previous comments) I wonder if it would be worth also saying
> that there may not be a need for the difference between successive counted
> values to be a constant increment (e.g., if order is truly the only needed
> property, without any "counter" nature).  Perhaps adding to the end ", or
> even for the difference between successive values to be predictable" would
> be a minimal-ish change, though I'm still on the fence as to whether it's
> worth saying [in this document].
> 
> >     A node that implements a per-context linear function may share the
> >     increment space among different contexts (please see the "Simple
> >     Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]).
> >     Sharing the same increment space allows an attacker that can sample
> >     identifiers in other context to e.g. learn how many identifiers have
> >     been generated between two sampled values.
> > 
> >     Finally, some implementations have been found to employ flawed PRNGs.
> >     See e.g.[Klein2007].
> > ---- cut here ----
> > 
> > The above still gives context for the bullets, but reduces the amount of 
> > text and the amount of unnecesary details/examples here.
> > 
> > I'd probably prefer addressing your comment with the modified text, but 
> > I would still be fine with removing the text if you prefer.
> 
> I think we can get the modified text to work; thanks for putting it
> together.  Would you also be able to stub out what it would look like to
> just make this modified text *be* the list itself?  E.g., "Employing
> trivial algorithms for generating the identifiers, which means [...]",
> "Employing the same identifier across contexts in which constancy is not
> required -- when one identifier is imployed [...]", etc.  I think we might
> have to see what that looks like before we can decide whether or not it
> will work.
> 
> > 
> > [....]
> > > 
> > I've added this one above. Thanks!
> > 
> > 
> > 
> > > 
> > > Section 5
> > > 
> > Good grief! I'll add a note to the Intro.
> > 
> > 
> > I'm not sure if the two words convey the same meaning. You might 
> > probably know better than me fore this one (i.e. "English as second 
> > language"). Not sure if someone might interpret "functional 
> > requirements" as a vague description of what the transient numeric ID is 
> > for (e.g. "identifying packets") as opposed to detailed requirements 
> > such as "monotonically increasing...".
> > 
> > That said, no matter which specific term we employ, I guess it might 
> > helps to add a parenthesis with something like:
> > 
> > 
> > "(e.g. required properties such as uniqueness, along with the failure 
> > mode if such properties are not met)"
> 
> This is good; we should probably take it.
> 
> > Thoughts?
> 
> In light of the discussion here, I think it is okay to stick with
> "interoperability".  I might consider going with "core interoperability",
> in an attempt to emphasize that we are looking for the actual fundamental
> requirements, not just the stuff that the protocol authors put in as MUST
> because they felt like it, but I think just "interoperability" would work,
> too.
> 
> > 
> > 
> > How about if we remove the redundant text from the lead-in?
> 
> So, just
> 
> % critical for the security and privacy considerations to:
> 
> ?
> 
> That looks like it would work.
> 
> > My take is that an analysis of any specified numeric IDs is also key for 
> > the "Privacy Considerations" that are expected in RFCs these days. So, 
> > while not mandatory, I'd expect that specs that explicitly do this 
> > homework will have more chances of avoiding these problems.
> 
> Indeed.
> 
> > > 
> > > Section 7
> > > 
> > How about changing this to:
> > 
> >     that the security and privacy implications of transient numeric
> >     identifiers are considered when writing the "Security Considerations"
> >     section of future RFCs.
> > 
> > ?
> 
> Works for me.
> 
> > 
> > 
> > > Section 9.1
> > > 
> > Definitely.
> > Done.
> > Done!
> > Thanks *a lot* for your comments! They have been really useful.  -- 
> > Please do let us know what you think about the few open issues above 
> > and, whether we should rev the document after that.
> 
> I think we have gotten as far as we can get just by talking about potential
> changes, so please go ahead and rev the document so we can see the changes
> and have a chance to change our mind back :)
> 
> Many thanks,
> 
> Ben

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Jul 2020 23:33:18 -0300

Hello, Benjamin,

In-line....

On 21/7/20 00:39, Benjamin Kaduk wrote:
> Hi Fernando,
> 
> Oops, it looks like I failed to actually cc: SAAG on my initial
> comments like I had planned to.  I will send the responses here
> (inline) that I already wrote up, but expect to re-send them to the
> saag thread after I forward my initial review there.  Sorry about
> that!

Yep.. I thought I was missing something, cause I couldn't find anything
sent or CC'ed to saag. :-)

[....]
>>> Section 2
>>> 
>>> What's wrong with the RFC 4949 definition of "identifier"? (We'd
>>> still want to keep the discussion about "transient", of course.)
>> 
>> To be honest, we missed there was this definition of "identifier"
>> in the RFC series. That said, the definition in RFC4949 also
>> acommodates non-numeric identifiers, for which the concept of e.g.
>> "linear" , monotonically-increasing, etc. would not apply.
> 
> This is true (and I was not sure whether pulling in 4949 for a
> single definition was going to help much -- it doesn't cover any of
> the other things we need).
> 
>> I would suggest that we replace this definition of "identifier"
>> with the definition of "transient numeric identifier", which is the
>> specific identifiers we're concerned with here.
> 
> That seems like a really good approach (especially since we
> explicitly say we will use the shorter term to refer to the same
> thing in this document).

Will do. Thanks!

[....]
>> 
>>> Implementing only part of a spec is a problem, but if we want to
>>> lament lack of adoption of follow-on updates, we should be
>>> writing things differently.
>> 
>> What we meant here is that this is a case where you might face
>> security issues arising from flawed transient numeric IDs, but this
>> has nothing to do with suboptimal specs, but rather with suboptimal
>> implementations (and in that sense there's not much we (IETF) can
>> do about them).
> 
> Sure.  "The right thing to do is properly specified (whether in a
> given document or an update to it), but the implementation just
> didn't do the right thing."

Will clarify this as suggested. Thanks!

>>> interoperability requirements for the transient numeric
>>> identifiers they specify, the constraints in the possible
>>> algorithms to generate them, as well as possible
>>> over-specification of such identifiers, become evident.
>>> Furthermore, requiring specifications to include a
>>> 
>>> nit(?): I'm not sure whether "constraints" is the right word here
>>> -- what is being constrained, and by whom?  Would "limitations"
>>> or "risks" be workable?
>> 
>> Probably an issue of "English as second language" here, sorry: I
>> guess we could have used "requirements" instead of "constraints".
>> i.e., what we meant is that if you spell out the interoperability
>> requirements, two things will become evident:
>> 
>> 1) The very "function" the algorithm needs to implement (e.g. if
>> you need monotonically-increasing IDs, you better make sure that a
>> new transient ID is larger than its predecesario), and,
>> 
>> 2) It would become evident when you are overspecifying things
>> (.e.g, monotonically-increasing IDs need not be a global counter
>> that starts at 0 -- that's not necessary to achieve
>> monotonically-increasing IDs).
> 
> actually want is to keep "constraints", but s/in/on/ -- the
> "constraints on the possible algorithms" are exactly the "function
> the algorithm needs to implement", which leads nicely into the
> "possible over-specification" that matches your point (2).

Awesome! Will fix this.

>>> security and privacy analysis of the transient numeric
>>> identifiers they specify prevents the corresponding
>>> considerations from being overlooked at the time a protocol is
>>> specified.
>>> 
>>> [*] I really don't think this is an appropriate way to phrase
>>> what we're doing.  To specifically *require* authors to include
>>> an analysis that covers these particular points seems to be quite
>>> a divergence from RFC 3552 -- while the presence of a security
>>> considerations section in RFCs is required, what RFC 3552 claims
>>> to provide is just guidelines for how to write such a section.
>>> Isn't what we're doing here just an incremental addition to that
>>> guidance, not a new hard requirement on authors?
>> 
>> Indeed.
>> 
>> transient numeric identifiers will help identify possible
>> algorithms that could be employed to generate them, and also make
>> evident if such identifiers are being over-specify. A protocol
>> specification
> 
> ("over-specified")
> 

Great! Will do.

>>> Section 4
>>> 
>>> [*] Similarly to Section 3, this section felt significantly
>>> longer than I was expecting.  Could you say something about the
>>> motivation for putting content here as opposed to (e.g.) 
>>> draft-irtf-pearg-numeric-ids-generation?  (Note, this section
>>> currently references draft-gont-predictable-numeric-ids, which is
>>> IIRC the pre-split consolidated document.)
>> 
>> We were not sure if sentences such as "Employing the same
>> identifier across contexts in which constancy is not required" or
>> "Employing the same increment space across different contexts"
>> would make sense to the reader without any context.
>> 
>> I can think of two options to address your comment: 1) Keep the
>> list, and point to draft-irtf-pearg-numeric-ids-generation right
>> after that.
>> 
>> 2) Strip much of the contents of this section (notably the
>> specific examples) as follows:
>> 
>> ---- cut here ---- Employing trivial algorithms for generating the
>> identifiers means that any node that is able to sample such
>> identifiers can easily predict future identifiers employed by the
>> victim node.
>> 
>> When one identifier is employed across contexts where such
>> constancy is not needed, activity correlation is made made
>> possible.  For example, employing an identifier that is constant
>> across networks allows for node tracking across networks.
>> 
>> security and privacy of the protocol re-using the identifier to
>> the security and privacy properties of the original identifier
>> (over which the protocol re-using the identifier may have no
>> control regarding its generation).  Besides, when re-using an
>> identifier across protocols from different layers, the goal of of
>> isolating the properties of a layer from that of another layer is
>> broken, and the privacy and security analysis may be harder to
>> perform, since the combined system, rather than each protocol in
>> isolation will have to be assessed.
> 

;-)

>> sequence, timing, etc.).  In many cases, there is no reason for
>> the corresponding counter or timer to be initialized to any
>> specific value e.g. at system bootstrap.
> 
> (Unrelated to previous comments) I wonder if it would be worth also
> saying that there may not be a need for the difference between
> successive counted values to be a constant increment (e.g., if order
> is truly the only needed property, without any "counter" nature).
> Perhaps adding to the end ", or even for the difference between
> successive values to be predictable" would be a minimal-ish change,
> though I'm still on the fence as to whether it's worth saying [in
> this document].

I'll add it. And will also try to add this to the relevant PEARG 
document (in case we missed this).

>> Sharing the same increment space allows an attacker that can
>> sample identifiers in other context to e.g. learn how many
>> identifiers have been generated between two sampled values.
>> 
>> Finally, some implementations have been found to employ flawed
>> PRNGs. See e.g.[Klein2007]. ---- cut here ----
>> 
>> The above still gives context for the bullets, but reduces the
>> amount of text and the amount of unnecesary details/examples here.
>> 
>> I'd probably prefer addressing your comment with the modified text,
>> but I would still be fine with removing the text if you prefer.
> 
> together.  Would you also be able to stub out what it would look like
> to just make this modified text *be* the list itself?  E.g.,
> "Employing trivial algorithms for generating the identifiers, which
> means [...]", "Employing the same identifier across contexts in which
> constancy is not required -- when one identifier is imployed [...]",
> etc.  I think we might have to see what that looks like before we can
> decide whether or not it will work.

You mean incorporate each piece of text into the corresponding bullets?
Or removing the bullets an just keep the text?  Or keep the bullets but 
just try to put the text bellow together in the same para? Or avoid 
using the bullets, and have something like:

---- cut here ----
    This section briefly notes common flaws associated with the
    generation of transient numeric identifiers.  Such common flaws
    include, but are not limited to:

    Employing trivial algorithms (e.g. global counters) that result in
    predictable identifiers, which means that any node that is able to
    sample such identifiers can easily predict future identifiers
    employed by the victim node.

    Employing the same identifier across contexts in which constancy
    is not required, thus allowing for activity correlation -- as in
    the case where the use of an identifier that is constant across
    networks allows for node-tracking.

    Re-using identifiers across different protocols or layers of the
    protocol stack, breaking the goal of isolating the properties of a
    layer from those of another layer, and also making the
    privacy and security analysis may be harder to perform, since the
    combined system, rather than each protocol in isolation, will have to
    be assessed.

    Initializing counters or timers to constant values, when such
    initialization is not required, thus unnecessarily leaking
    information (e.g., "system uptime" if a timer is reset to zero
    when the system is boot-strapped).

    Employing the same increment space across different contexts, where
    a per-context linear function shares the increment space among
    different contexts, thus allowing an attacker that can sample
    identifiers in other context to e.g. learn how many identifiers have
    been generated between two sampled values.

---- cut here ----

I wouldn't mind doing it in this way... although, the very first 
paragraph of Section 4 kind of introduces a list, so I'd rather make the 
above list a bulleted list.

(Still, I think the stripped-down version with the bullets is a bit more 
clear)

    -- I can do two versions of the I-D, with these two options so that 
we can check how the text looks & feels on the real doc. And then we 
choose and post the one that looks best...

[....]
>> probably know better than me fore this one (i.e. "English as
>> second language"). Not sure if someone might interpret "functional 
>> requirements" as a vague description of what the transient numeric
>> ID is for (e.g. "identifying packets") as opposed to detailed
>> requirements such as "monotonically increasing...".
>> 
>> That said, no matter which specific term we employ, I guess it
>> might helps to add a parenthesis with something like:
>> 
>> 
>> "(e.g. required properties such as uniqueness, along with the
>> failure mode if such properties are not met)"
> 
> "interoperability".  I might consider going with "core
> interoperability", in an attempt to emphasize that we are looking for
> the actual fundamental requirements, not just the stuff that the
> protocol authors put in as MUST because they felt like it, but I
> think just "interoperability" would work, too.

Good point. Will do.

[...all other agreed-upon changes applied...]
>> Thanks *a lot* for your comments! They have been really useful.
>> -- Please do let us know what you think about the few open issues
>> above and, whether we should rev the document after that.
> 
> I think we have gotten as far as we can get just by talking about
> potential changes, so please go ahead and rev the document so we can
> see the changes and have a chance to change our mind back :)

Please let me know what you think e.g. about the above two options.. and 
I will produce one or two versions of the doc for us to check -- and 
then, we pick the one we're more comfortable with, and get it posted.

Thoughts?

Thanks a lot!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492