Re: [Sidrops] RFC 8360 / 6487

Job Snijders <job@fastly.com> Fri, 15 January 2021 13:30 UTC

Return-Path: <job@fastly.com>
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 35BF83A0D00 for <sidrops@ietfa.amsl.com>; Fri, 15 Jan 2021 05:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
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 hPxmkQEj44wU for <sidrops@ietfa.amsl.com>; Fri, 15 Jan 2021 05:30:19 -0800 (PST)
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898013A0CFE for <sidrops@ietf.org>; Fri, 15 Jan 2021 05:30:19 -0800 (PST)
Received: by mail-wr1-x441.google.com with SMTP id a12so9263562wrv.8 for <sidrops@ietf.org>; Fri, 15 Jan 2021 05:30:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=r30X/y6aDipgSRkJ20Ji/X6bxp4JmHEd9ULGFY963gk=; b=L6lh4k30kKoEcK57hU/bc1AJxNLLtbX8qkty49wl4VMYYKPwsPZSyx+qNNng33Aff3 nJVdvOz2AT+wM+UHTb4S6uyfGEvUdlDWqe7/nVjequUcp5CP12w4g0FSG9L8MrzVUdOu cgb+9x5PlU8f6GzwfcP2KIvFLpDNmnBlReIbE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=r30X/y6aDipgSRkJ20Ji/X6bxp4JmHEd9ULGFY963gk=; b=PW29uCZYSEYYuTNKMK/Ht5lhzyUrlhjOcOD3S4FqCRBlVIqRVD7G743SV3h75QsToh Afqed2POQtI+WBttAp5pefd7oFtgDwUVatGy7AB69Y3+EZov0Ew1w/cWWZF2mHv63Ij+ 6ZOEFY/Uf9rZkcZ21nfxYzDjgv4QnJ8poaGx2D7/RLKzl0aO1pj3fytNf05OfRP0lT5u ZrXspTszZ5IoHSRsGVCRzyEjtnQWu7ZcdGTs2bnMJJ0LQhAJl4AyX83CK5Dbg4IRnfe2 1CJt69zCsBnIy5CsRBPxn/JrP6wgr3z+2giPiR8fGk+gqKJSXvWJGtHJ8BHBL/PQSgoY UuZA==
X-Gm-Message-State: AOAM530SetcTcI4excu7FQ7K+Mw2MsO5anvG+EFh46m9r32UxuL1hiZ2 MfymKdX4ykJoiy6xtDOMuT+3r42ntqdJAfNb1EForz6tFF0qWORrev54zy5Et0PRrmh6pXITj4k PPS6meyE9/IeVZWxxljCCOn4Zycrg5NCfpX/sadf+0xIlTKyD9+2+ZkyLxg==
X-Google-Smtp-Source: ABdhPJyE8suUjt7FBn+GZ83MTEs6xwpJJJGpIz0BWKkyO8Mgo4RId6VVVGecgP8RhYSLf4Eay8LLlQ==
X-Received: by 2002:a5d:40d2:: with SMTP id b18mr12956436wrq.369.1610717417425; Fri, 15 Jan 2021 05:30:17 -0800 (PST)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id c16sm14648942wrx.51.2021.01.15.05.30.15 for <sidrops@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Jan 2021 05:30:17 -0800 (PST)
Received: by snel (sSMTP sendmail emulation); Fri, 15 Jan 2021 14:30:15 +0100
Date: Fri, 15 Jan 2021 14:30:15 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <YAGY59BxxlEQy+ip@snel>
References: <X/34H009eeuRcUf1@bench.sobornost.net> <2528A2B4-D5C6-4803-847E-3D138D4C5E14@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2528A2B4-D5C6-4803-847E-3D138D4C5E14@nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7A3mkeukh92CrKKYFIJPmq9wHaU>
Subject: Re: [Sidrops] RFC 8360 / 6487
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, 15 Jan 2021 13:30:21 -0000

Dear Tim,

On Fri, Jan 15, 2021 at 12:21:50PM +0100, Tim Bruijnzeels wrote:
> This might be of renewed interest:
> https://tools.ietf.org/html/draft-va-sidrops-deploy-reconsidered-01
> 
> Presented at IETF104:
> https://www.ietf.org/proceedings/104/slides/slides-104-sidrops-deployment-of-validation-reconsidered-00

Thank you for these pointers, very informative.

It is now clear to me rpki-client has some work to do in order to
participate in progressing the deployment of the reconsidered validation
strategy in some form. It all starts with implementing support for RFC 8360 :-)

> The 8360 approach had some controversy in the past. But I would be
> happy to see a constructive discussion on its deployability. The
> document above is an attempt at starting that dialogue.

There being an OID (and thus a role for CAs to play in deploying 8360)
is a double-edged sword: one the one hand a large enough CA could
attempt to force the market to adopt the reconsidered validation
strategy by setting the new OID, on the other hand the CA might not be
large enough to pull that off.

It seems in the best interest of Relying Parties to not reject
overclaiming CAs, and in the best interest of CAs for their constituent
Relying Parties to use the revised strategy. I think George aptly
characterizes this as a 'community-wide risk'.

To me it seems the way the incentives are stacked, deploying a revised
strategy /should/ exclusively be a 'validator problem', rather than
something where CAs need to take action. However, a new OID having been
defined makes deployment a challenge which cannot exclusively be
resolved by just upgrading the validators, now it potentially involves
tens of thousands of Certificate Authorities. I can imagine how some
controversy came to be.

Looking at my publication point's log files it appears 95% of relying
parties upgrade *at least* once every 15 months. Any deployment plan
with *more* dependencies than 'just RPs upgrading their validators',
will have to take such numbers into consideration, and unfortunately
there is the risk of new (not revised) validators joining the ecosystem
in the next 15 months.

I have some todo items on this topic, I'll report back later. Thanks
again for your information and pointer to deploy-reconsidered draft!

Kind regards,

Job