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

[Benjamin Kaduk <[e-mail]>]

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