[Pearg] Tsvart early review of draft-irtf-pearg-numeric-ids-generation-02

Michael Tüxen via Datatracker <noreply@ietf.org> Fri, 07 August 2020 12:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pearg@irtf.org
Delivered-To: pearg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 186903A0B90; Fri, 7 Aug 2020 05:22:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Michael_T=C3=BCxen_via_Datatracker?= <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: pearg@irtf.org, draft-irtf-pearg-numeric-ids-generation.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159680292803.8931.4890868238678597521@ietfa.amsl.com>
Reply-To: =?utf-8?q?Michael_T=C3=BCxen?= <tuexen@fh-muenster.de>
Date: Fri, 07 Aug 2020 05:22:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/LAPWeg1HIpPaxrndXgBr1jTdJ1k>
X-Mailman-Approved-At: Mon, 10 Aug 2020 11:33:35 -0700
Subject: [Pearg] Tsvart early review of draft-irtf-pearg-numeric-ids-generation-02
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2020 12:22:08 -0000

Reviewer: Michael Tüxen
Review result: Ready with Issues

The document is well written, provides algorithms which could be used to
address identified problems. One  could add some text covering TCP timestamps.

Section 1 states:
"Recent history indicates that when new protocols are standardized or
new protocol implementations are produced, the security and privacy
properties of the associated identifiers tend to be overlooked,..."
How does this related to recent/current activities like SCTP/DTLS or QUIC?

The Algorithms in 7.1.1 and 7.1.2 can be substantially simplified when
check_suitable_id() always returns true. Why are not the simplified algorithms
shown?

The algorithm in 7.3 (and later) uses a function F and it is stated that F must
be a cryptographically-secure hash function. Couldn't you also use something
like SipHash.

When reading the algorithm in 7.4.1, I had the impression that it should also
work with id_inc > 1 (by just changing that parameter). If that is true, I
guess you would need to change "if (next_id == max_id)" to "if (max_id -
next_id < id_inc) {" and also "next_id = min_id;" to "next_id = min_id +
(id_inc - (max_id - next_id + 1));".  If you don't want to be that generic, you
might want to remove id_inc and just use 1.

The algorithm in 7.4.1 also calls "store_counter(CONTEXT, next_id)" when
returning ERROR. Why?

The algorithms given before 9.4 are given in C code. The Algorithm in 9.4
breaks with this rule. Is this intended?

Nits:
Page 10: if(check_suitable_id(next_id)) -> if (check_suitable_id(next_id))
Page 11: if(check_suitable_id(next_id)) -> if (check_suitable_id(next_id))
Page 12: if(check_suitable_id(next_id)) -> if (check_suitable_id(next_id))
Page 14: if(lookup_counter(CONTEXT) == ERROR){ -> if (lookup_counter(CONTEXT)
== ERROR) { Page 14: if (check_suitable_id(next_id)){ -> if
(check_suitable_id(next_id)) { Page 14: }\n else { -> } else { Page 16:
if(check_suitable_id(next_id)) -> if (check_suitable_id(next_id)) Page 18:
if(check_suitable_id(next_id)) -> if (check_suitable_id(next_id)) Page 24:
linear(CONTEXT_2)= linear(CONTEXT_2) + increment(); -> linear(CONTEXT_2) =
linear(CONTEXT_2) + increment(); Page 24: if(check_suitable_id(next_id)) -> if
(check_suitable_id(next_id))