Last Call Review of draft-gont-numeric-ids-sec-considerations-06

Request Review of draft-gont-numeric-ids-sec-considerations
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2021-01-04
Requested 2020-12-07
Authors Fernando Gont, Ivan Arce
Draft last updated 2020-12-25
Completed reviews Tsvart Last Call review of -06 by Bernard Aboba
Genart Last Call review of -06 by Gyan Mishra
Secdir Last Call review of -06 by Charlie Kaufman
Assignment Reviewer Bernard Aboba 
State Completed
Review review-gont-numeric-ids-sec-considerations-06-tsvart-lc-aboba-2020-12-25
Posted at
Reviewed rev. 06
Review result Not Ready
Review completed: 2020-12-25


This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

 The purpose of this document appears to be to distill lessons from
draft-irtf-pearg-numeric-ids-history and draft-irtf-pearg-numeric-ids-generation
(both of which I found informative) into actionable advice for draft authors. 

However, the document's Section 5 contains no normative statements and
recommendation 2 is seems somewhat too broad in introducing a privacy
considerations requirement. It may be possible to fix this Section by
couching recommendations 1 and 3 probably as mandatory and focusing
recommendation 2 on security while citing the details of  potential 
security vulnerabilities covered in  draft-irtf-pearg-numeric-ids-generation Section 8. 

An alternative to a BCP might be to attempt to achieve the goals in
some other way, such as adding the issues raised in the
predecessor documents to those considered in Directorate reviews. 

Overall, if the intent is to move the IETF toward requiring privacy considerations in
documents, more extensive guidance is required than is provided here. 
For example, SDOs such as the W3C now expend considerable effort on 
identifying issues relating to fingerprinting, a topic which is only touched on in
this document.

The emphasis appears to be not on privacy issues in general as on implementation
lessons learned from the use of transient identifiers used in unsecured protocols. 
If so, a BCP may not be the best way to influence implementers.  If the focus is
to be on draft authors, then as the IETF addresses some of the
security gaps (e.g. QUIC versus TCP, DNS privacy)  it would be useful to clarify how
much of the advice remains relevant (e.g. which advice applies to fields that lack
confidentiality and/or integrity protection,  what threats persist even with end-to-end

Specific comments: 


   Poor selection of transient numerical identifiers in protocols such
   as the TCP/IP suite has historically led to a number of attacks...
   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.

[BA] For a privacy analysis, why focus only on "transient" numeric identifiers?

1.  Introduction

   Network protocols employ a variety of transient numeric identifiers...

  poor selection of numeric identifiers, usually as a result of...

[BA] The first paragraph mentions "transient numeric identifiers" whereas
the second paragraph just uses the term "numerical identifiers", potentially
broadening the scope of concern to issues such as fingerprinting. Was this

  o  Predictable TCP sequence numbers

   o  Predictable transport protocol numbers

   o  Predictable IPv4 or IPv6 Fragment Identifiers

   o  Predictable IPv6 IIDs

   o  Predictable DNS TxIDs

[BA] References?  Is the intent to restrict the examples only to unsecured protocols and fields sent in cleartext?

As  a  result, advice in this area is warranted.

[BA] A BCP needs to go beyond "advice", to providing actionable (and normative) guidance.

3.  Issues with the Specification of Transient Identifiers

   Finally, there are protocol implementations that simply fail to
   comply with existing protocol specifications.  That is, appropriate
   guidance is provided by the protocol specification (whether the core
   specification or or an update to it), but an implementation simply
   fails to follow such guidance.  For example, some popular operating
   systems (notably Microsoft Windows) still fail to implement
   transport-protocol port randomization, as specified in [RFC6056].

[BA] Is the audience implementers or document authors? 

4.  Common Flaws in the Generation of Transient Identifiers

This Section would seem to fit well as a summary within draft-irtf-pearg-numeric-ids-history 

   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.

[BA] This can be relevant even if the identifier is encrypted (e.g. if the attacker is a website utilizing the identifier for fingerprinting). 

5.  Security and Privacy Requirements for Identifiers

   When a protocol specifies transient numerical identifiers, it is
   critical for the protocol specification to:

   1.  Clearly specify the interoperability requirements for the
       aforementioned identifiers (e.g., required properties such as
       uniqueness, along with the failure severity if such properties
       are not met).

   2.  Provide a security and privacy analysis of the aforementioned

   3.  Recommend an algorithm for generating the aforementioned
       identifiers that mitigates security and privacy issues, such as
       those discussed in [I-D.irtf-pearg-numeric-ids-generation].

[BA] Recommendations 1 and 3 seem reasonable, but probably should be couched in normative language. 
Recommendation 2 would appear to require reworking; the document is not specific enough to serve as
a guideline for a privacy considerations section. Perhaps a reference should be provided to the security
vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8.