Re: [Pearg] Brian Trammell's Yes on draft-irtf-pearg-numeric-ids-history-09: (with COMMENT)

"Iván Arce (Quarkslab)" <iarce@quarkslab.com> Thu, 16 June 2022 20:45 UTC

Return-Path: <iarce@quarkslab.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74035C15AE2D; Thu, 16 Jun 2022 13:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.985
X-Spam-Level:
X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=quarkslab.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEBUvGCiaCiC; Thu, 16 Jun 2022 13:45:27 -0700 (PDT)
Received: from mx5.quarkslab.com (mx5.quarkslab.com [163.172.30.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6FCC15AACA; Thu, 16 Jun 2022 13:45:27 -0700 (PDT)
Received: from [192.168.153.138] (unknown [186.189.238.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx5.quarkslab.com (Postfix) with ESMTPSA id 4LPDgK3KJCz7scr; Thu, 16 Jun 2022 20:44:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=quarkslab.com; s=mail; t=1655412319; bh=YbY5UUB5oB9PkTd1NMawJO+0vxJYU9E1vXu+xFMUiP0=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=hR08LJdta0QCk8coEm9CPPuWDDtC+Jy4fWkp9/cITbVrPIoL0ARxMAL2dRY5UuJh7 nYZazM7whhGX9ZPsgiKCRD/MIVF4RXG4MM8BmR8gU1a/zAdvdkEg222IK1d9H8JE87 U7MVkOk4EDOmSJMKbe5M4tbl3omjGKVJZtYaCuvo=
Message-ID: <cc48460b-7ce4-00f0-85b0-9c579b8cc51b@quarkslab.com>
Date: Thu, 16 Jun 2022 17:44:26 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: Brian Trammell <trammell@google.com>, The IRSG <irsg@irtf.org>
Cc: draft-irtf-pearg-numeric-ids-history@ietf.org, pearg-chairs@ietf.org, pearg@irtf.org, sara@sinodun.com, Fernando Gont <fgont@si6networks.com>
References: <165538883599.60682.16650863205769317634@ietfa.amsl.com>
From: "Iván Arce (Quarkslab)" <iarce@quarkslab.com>
In-Reply-To: <165538883599.60682.16650863205769317634@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/RdajF4gIW_r70AR0S3q2ZafbYFE>
Subject: Re: [Pearg] Brian Trammell's Yes on draft-irtf-pearg-numeric-ids-history-09: (with COMMENT)
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Thu, 16 Jun 2022 20:45:31 -0000

Hello Brian

my comments below

On 6/16/22 11:13, Brian Trammell via Datatracker wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This document is ready for publication on the IRTF stream.
> 
> Two questions, though (my Yes here does not depend on the answers):
> 
> (1) I notice that most of the chronologies seem to shift from academic
> citations to I-Ds and don't shift back; did academia lose interest in these
> issues at that time, or did the literature search only cover the time before
> the discussion moved to various IETF working groups?

It is hard to tell if academia lost interest in those topics. The 
security practitioners certainly have kept looking for the same issues 
(and finding them) in new protocol implementations, for example in the 
stacks used by IoT devices.

On the academic side, I think there may be two trends at play:

1- Interest have moved up stack, to the session/app layer and therefore 
there isn't so much focus on

2- There is a marked tendency towards thinking that cryptography solves 
this type of issue. That is partially truth, indeed transport layer 
security that provide certain guarantees to numeric ID fields at the 
protocol level, address several of the issues we mention, but not all of 
them. Particularly cryptography isn't particularly good for solving MATE 
(Monkey-At-The-End) problems, in which a legitimate peer can take 
advantage of weak numeric ID generation algorithms to infer internal 
state from the counterpart or to attack other peers.

In any case, we believed that having these issues addressed at the IETF 
level would help to fix them, or at least reduce their occurrence, at 
the root level and thus wanted to properly reference those efforts.

> 
> (2) The document has a significant number of informative references to
> abandoned I-Ds. Were these submitted for adoption by the associated WGs (i.e.,
> it'd be interesting to know if the WG process failed to address mitigations for
> these identification issues), or merely intended as points of discussion?
> 

The first version of the I-D is from 2016 so you can imagine that along 
the timeline several of the referenced I-Ds evolved in different ways, I 
have not looked at the details but I think most of them were adopted as 
work items by the WGs and some of the issues we pointed out were 
incorporated in drafts that were then worked on. I believe Fernando may 
have a better view of how that process went.

Regards,
/ivan

-- 
Iván Arce
Chief Research Officer
Quarkslab