Re: [v6ops] [EXTERNAL] Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 04 August 2020 00:09 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B133A118D; Mon, 3 Aug 2020 17:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bGfbgzDDh-Rp; Mon, 3 Aug 2020 17:09:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A1E3A118B; Mon, 3 Aug 2020 17:08:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7382B389A2; Mon, 3 Aug 2020 19:47:49 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RFttO6ZPSUGj; Mon, 3 Aug 2020 19:47:44 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D9B23389A0; Mon, 3 Aug 2020 19:47:43 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6302E63E; Mon, 3 Aug 2020 20:08:21 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
In-Reply-To: <a43ffd94d6364a0f869cd4c694ab7432@boeing.com>
References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <CAFU7BARePzdeU5DFgoOWyrF0xZCj67_xkC2t8vMN2nH0d8aUig@mail.gmail.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <CAFU7BATiD8RkiWXjrxGuAJU-BUwRQCErYZivUPZ-Mc_up_qGxQ@mail.gmail.com> <aebc46c9b813477b9ae0db0ef33e7bd9@huawei.com> <CAO42Z2yL7+GbO6QRaNzFYoBXLF-JZ2NfwgTTt2zerKhJLwt2Lw@mail.gmail.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <a43ffd94d6364a0f869cd4c694ab7432@boeing.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 03 Aug 2020 20:08:21 -0400
Message-ID: <17695.1596499701@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/eX0jMD0DXO71463QH42EAmDheCk>
Subject: Re: [v6ops] [EXTERNAL] Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 00:09:16 -0000

SEND is/was too expensive to deploy because 15 years ago, hosts did not have
identities that other hosts or routers could easily validate.
We did not come up with a reasonable TOFU mechanism either.

I believe that there are probably now environments (such as yours Fred) where
the cost/benefit of deploying those identities now has become positive.
This because the cost of deploying identities is much lower than it used to
be (both the administrative cost of doing it, as well as the CPU/network cost
of doing the signing), while the benefit of mitigating the risks is higher.

But, this has gone beyond GRAND.
GRAND is useful without SEND, but would be enhanced by SEND.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-