Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt

Robert Kisteleki <robert@ripe.net> Fri, 06 March 2020 14:18 UTC

Return-Path: <robert@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A613A079A for <sidrops@ietfa.amsl.com>; Fri, 6 Mar 2020 06:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 WMVzmYyBMG0B for <sidrops@ietfa.amsl.com>; Fri, 6 Mar 2020 06:18:03 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 27F383A0799 for <sidrops@ietf.org>; Fri, 6 Mar 2020 06:18:03 -0800 (PST)
Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <robert@ripe.net>) id 1jADnd-00070B-Qc for sidrops@ietf.org; Fri, 06 Mar 2020 15:18:01 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::3d6]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from <robert@ripe.net>) id 1jADnd-00080Z-OM for sidrops@ietf.org; Fri, 06 Mar 2020 15:18:01 +0100
References: <157914534015.22379.11024327123542212494@ietfa.amsl.com> <CAL9jLabyFSP0C1Rq3FY6JkJVbPbm9yG9JuAfMQeZZtEeSb0Dfg@mail.gmail.com> <CAKr6gn11jN5Jb+uTeQerSktE5mE_DH+rSiBeYc90dpJqsAXGig@mail.gmail.com> <920CAE43-E94A-45A1-AD2C-86095F396E96@nlnetlabs.nl>
From: Robert Kisteleki <robert@ripe.net>
Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd
Organization: RIPE NCC
To: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <c0774788-c572-7dd1-8b15-41bee5af16c6@ripe.net>
Date: Fri, 06 Mar 2020 15:18:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <920CAE43-E94A-45A1-AD2C-86095F396E96@nlnetlabs.nl>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ACL-Warn: Delaying message
X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274e6c7dc57edf436d7ebefba7eeb876f18
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3M64nxSBoLEDq_r59Z28Ltge0DM>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 14:18:05 -0000


On 2020-03-04 09:55, Tim Bruijnzeels wrote:
> Hi,
> 
> I believe that we should discuss the concerns raised by Rob. Whether that is in the context of a working group last call or not.. I don't really mind the process.

Hi,

Thank you Tim for your thoughts. I do agree that more discussion is
warranted about pros/cons for this approach. Perhaps a wider threat
modelling would be useful.

Speaking for myself only: I believe that at the end of the day the
in-band approach the draft proposes has more downsides than upsides.
YMMV. Now, if there weren't alternative approaches, then I'd also say
"it addresses a perceived problem so why not?" -- but there *are*
real-life alternatives. George reiterated a few:

>> Rob suggested we consider why browsers ship TA changes by updating
>> code. That moves the burden to a body who agrees what TAL need to be
>> shipped, and liaison with the Validator authors and release processes.
>>
>> Or, a hand-run process to use this mechanism.

(BTW I did not suggest this :-)

>> Or, a signalling mechanism to flag "this TAL needs to change" but the
>> actual decision to change, is hand-managed buy the RP.

My ordering would put (3) on top, closely followed by (1).

(3) has many upsides: it can warn the operator if there's a TAL change
*even if* the software is otherwise not upgraded. This allows the
operator to do a manual double-check if that's desired. It even allows
an automatic update (I imagine it can be a RP software option). In other
words, it makes it the operators' decision to do the update in-band or not.

(1) is an example of how a mechanism for achieving comparable outcomes
works really well in a different context, on a much bigger scale. It
also leaves the operator in full control, if that's desired.


All in all, I'm not against this draft per se. But I do want to make
sure we consider if it provides the best approach to the problem.

Robert