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

[Fernando Gont <[e-mail]>]

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!




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

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

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

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



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

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.

    Finally, some implementations have been found to employ flawed PRNGs.
    See e.g.[Klein2007].
---- 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...




[....]
>>> 1.  Clearly specify the interoperability requirements for the 
>>> aforementioned identifiers.
>>> 
>>> Hmm, would it be fair to say "interoperability (i.e.,
>>> functional)"?
>> 
>> 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.

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