[Tsv-art] Tsvart last call review of draft-gont-numeric-ids-sec-considerations-06

Bernard Aboba via Datatracker <noreply@ietf.org> Fri, 25 December 2020 10:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDE63A124D; Fri, 25 Dec 2020 02:26:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bernard Aboba via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: draft-gont-numeric-ids-sec-considerations.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160889198345.3885.12485634387688330689@ietfa.amsl.com>
Reply-To: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, 25 Dec 2020 02:26:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/eGP2QZYU2D_xHI6Awp-bJypREX0>
Subject: [Tsv-art] Tsvart last call review of draft-gont-numeric-ids-sec-considerations-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Dec 2020 10:26:24 -0000

Reviewer: Bernard Aboba
Review result: Not Ready

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
tsv-art@ietf.org 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 security).

Specific comments:

Abstract

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

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

   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.