Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice

Martin Thomson <mt@lowentropy.net> Thu, 17 December 2020 06:07 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055173A14AC for <last-call@ietfa.amsl.com>; Wed, 16 Dec 2020 22:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=eqgts3+p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZD9Aprx1
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxoU1iz98__P for <last-call@ietfa.amsl.com>; Wed, 16 Dec 2020 22:07:23 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A5A3A14AB for <last-call@ietf.org>; Wed, 16 Dec 2020 22:07:23 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A0F9D7DA for <last-call@ietf.org>; Thu, 17 Dec 2020 01:07:22 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 17 Dec 2020 01:07:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=8P1K4Dv62Fottn3LmEzRbdVqCujtVwv LI4sPnXqrrkY=; b=eqgts3+p7LeSW7j/D3hbzsFZ/2otGj0jHS5dxRFb/rxSDqf /iCFcYRW7u3UZ70LH+wH1e7Tn23Os4NIuRhuWmuTNJ/H8KFXWOvg1aoFO1vLJt7e ww9L8dyTPRtXqUkjGnozAHTH50IavnGdW4rLGjInpzPsLJTUwKGESTeu2YTjkJXE Y0cDmz+xDJKk8YiUqUWNVb7exuEyci74wDBpqoyODmciMqyFaO3u4FHVTIaJzDxa OgFc53sjOLyyro3blPXwgP7x1UzJ1KutcdMCneNxJTdSzJeW/S/R2dh/qTUfFXBW oRmuHL1DL+j16lB13MTqym23h6vGv0gFLrJKp2Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8P1K4D v62Fottn3LmEzRbdVqCujtVwvLI4sPnXqrrkY=; b=ZD9Aprx1t5dePxn3B1l48s YlXYvfoFij4DFYXyW2tx6m1i53iF9S94VNS7Hc0OxvbkS4rx+I53+QE0frcSHNgh uj2R9j5CADrOjPh5NG8ZZGapED/ACyP1cTVdypOlPv2C+IyagolVZvJb3+oyUE34 9JX9laBg2h4iTnFtaIuuOOaGd7L01I+8HxPkxEG4zRh2TtU/mofJY6jCOtViG3ty fIu4mW8uQzv4Am5sCaijFfw6h1IJ3YeFB1yZfRACch9nazih1e2CwfH7KisR3ril oyYSKI6QlMU8+zPSYg5EH+M0YAm4DEL6xGKaI/VkI95YIXWontzbFs1hC17fLRVA ==
X-ME-Sender: <xms:mfXaX2PXi5f-tFHvKcHXDskch_DuYt6C6a06wDqu21z13fhoeKph3Q> <xme:mfXaX0_DR9v67frkYP6cZsFpk9L3uLFGSNc-NyZEm3gPRv1-rWnVFPLBofWmQfIiZ 8H-loCBqq3zm3l1XsI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelfedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeelfedugfelgeeigfeuve eludejjeeutdelgedvteehueevhfdvhefggeeuffeivdenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:mfXaX9R6O11Lu64mHZ-qqs9Ukv5rBnVEdCDpIR9ZvXopOBjcmo67ng> <xmx:mfXaX2swAXu86sH6AFn_hDUY5diQZzZ6FYsSlnYipeT2iD9HBY3fvQ> <xmx:mfXaX-eD6RkcIczZmPZOqAHVfFKvYw6acOp08Gn2WGiW3IOGgEpflQ> <xmx:mvXaX4qrbI4E4zkhcILZVBVTIVNbARel6a62q7kM3UGRSfE9jfvgcw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8CD620063; Thu, 17 Dec 2020 01:07:21 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <a5d0aebb-7d56-4d1e-ae64-818c3c89c1c2@www.fastmail.com>
In-Reply-To: <2572a393-f5cc-42f3-7ddb-15a3ace26b47@huitema.net>
References: <CABcZeBPTk0zrm6iwJOiac6N7w_jYhtkoX3HeBci9tZ_Y8=uKVw@mail.gmail.com> <0FA1DBD3-8E38-4F0E-A8CC-725053B64CB8@strayalpha.com> <38ad33f9-3f79-dc3f-6919-b07fb5a499f4@si6networks.com> <4633ee35-f1d2-4db9-d7b8-8207e697c6bc@huitema.net> <ec064b2f-4ab0-dc64-52e4-b6dc319765b5@si6networks.com> <2572a393-f5cc-42f3-7ddb-15a3ace26b47@huitema.net>
Date: Thu, 17 Dec 2020 17:07:00 +1100
From: Martin Thomson <mt@lowentropy.net>
To: last-call@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/9M52hCZUwLWtAkxHOJCb9iNr7Uk>
Subject: Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 06:07:26 -0000

Everything else Christian says here about QUIC is accurate.  I see nothing there that suggests a problem in need of attention.  I would also point to https://tools.ietf.org/html/draft-ietf-quic-load-balancers for a more nuanced treatment of the connection ID selection problem.

On Thu, Dec 17, 2020, at 16:19, Christian Huitema wrote:
> An informational document documenting a series 
> of past attacks would be interesting and educational. The kind of rule 
> making proposed in the draft, on the other hand, would be mostly harmful.

...but this is the most important message.  Removing Section 5 and all that depends on it would make this a better document.

Separately, I found the list of potential problems in Section 4 to be approximately OK, though it lacked any mention of a need to synchronize changes across protocol layers.  I acknowledge that that is about use rather than generation, but that is quite relevant here too.