Re: [Sidrops] request for call for Working Group adoption draft-spaghetti-sidrops-rpki-validation-update

Job Snijders <job@fastly.com> Tue, 27 April 2021 11:14 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 BD3753A104C for <sidrops@ietfa.amsl.com>; Tue, 27 Apr 2021 04:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_DNSWL_BLOCKED=0.001, 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 cQ3QDJouBqW4 for <sidrops@ietfa.amsl.com>; Tue, 27 Apr 2021 04:14:45 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 E0C113A104D for <sidrops@ietf.org>; Tue, 27 Apr 2021 04:14:44 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id j28so5442877edy.9 for <sidrops@ietf.org>; Tue, 27 Apr 2021 04:14:44 -0700 (PDT)
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=in8LZgP+gHhTftX9jzPDQLHI/EtJiJUjXVWlrPPnmZM=; b=TL2CL1ueHcVUe1DeLM6Nwo3cecnNzr5WpcEArqXxCPobKJ+M3qNw2QETwSuIjOSLvp 1PObqEwnHSb42WkWbD57RJ6cMbPv03TtdlVP75IwF06H9pU3RWyM9wf4qTMbMHHZ0Sr/ 3qNeqpmzWtkKjhnn8NONxY/Gz3A/p4EEucUC8=
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=in8LZgP+gHhTftX9jzPDQLHI/EtJiJUjXVWlrPPnmZM=; b=GWzce2RkRQP/4c9hJfyLFE1P9rToRj0GCBGdQYVLBfvdmRgj1slMUc4reweJwAsSDU r5tUFe3TNrXEQfe+I8+1l/kxb78kAgU66WNObt9bZTF+GEOq7P644SrH3H+kMBZwmAfg +YaQinFPg+9OiKEdhgkzoB72CGY2zwrGw3yzYofLYMwnBmKlRRgb9sAAyPdIxlnRVTWZ Zek6DzEPi+CmTrnVqtTvWvMAQ7o6v0KYHWf19UcFqPOIymFzPrnw4jodVKVW59Tujc9D +0UkS1dnjIq7hki5m13kpF4ao/OT7v+2aaWa1OaXd2D5AYjCvAyMR+Msjh/GPmbFuqC5 /nNg==
X-Gm-Message-State: AOAM530DUfHSJxHRIlM3qyZB+8tn4iuH//yrZ3p5wJHikfypX1v8tG9t IdwgN5x7vFk3ujMzmqOdPw/DvbXCDsuGo2vDU83iavlGI/ZH3zTdSqVZO4kmp6qVQlB5y/rJoyN S6gauWuh0XoAsIOXw6ZFSk5Pj1vJLr79ujfETOK6IXPIJFwwoljctP7k=
X-Google-Smtp-Source: ABdhPJw/MZWOjbnD3Xk3w0nBRkthAE7bmjrvtplquCM4YgivLCnSQ9FlZ2EnfXM1bmcm74DPAuvRLA==
X-Received: by 2002:a05:6402:4a:: with SMTP id f10mr3592786edu.85.1619522081749; Tue, 27 Apr 2021 04:14:41 -0700 (PDT)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id u1sm2097191edv.90.2021.04.27.04.14.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Apr 2021 04:14:34 -0700 (PDT)
Date: Tue, 27 Apr 2021 13:14:33 +0200
From: Job Snijders <job@fastly.com>
To: The S in RPKI stands for Security <sidrops@ietf.org>
Message-ID: <YIfyGerDr5n9Ag2k@snel>
References: <YEjILk/5hwwX/x9P@snel> <m2pn07gl6g.wl-randy@psg.com> <YEjrr9IKijX1+5We@snel> <m2wnueg9ou.wl-randy@psg.com> <CAL9jLaaKZvqj8b8N-N6QUFXJbJVZQ2bzdEbz3sgt6GwugzXKsw@mail.gmail.com> <CAL9jLaaC=x0iqWUcD22Q8Dvcqr8+dCqnun+YDpqLQ7ABiApuOg@mail.gmail.com> <4d20e76a-6765-bc30-6441-b88ccf17e25d@foobar.org> <CAL9jLaaDkk49AA80ZMcHyg_Pq2ZRpE449zmtTCUWSzgPrmWFGw@mail.gmail.com> <m2pmymi3v7.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2pmymi3v7.wl-randy@psg.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3hg14oM0mw-OC8rF213GJaXla70>
Subject: Re: [Sidrops] request for call for Working Group adoption draft-spaghetti-sidrops-rpki-validation-update
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: Tue, 27 Apr 2021 11:14:50 -0000

On Thu, Apr 22, 2021 at 11:14:04AM -0700, Randy Bush wrote:
> while i suspect that idr will not be overly excited, i am fairly sure
> the security community, especially the pki folk, will be *very*
> interested

The 'security community' is most welcome to provide review! Please
invite them. They should be interested! I look forward to read actual
arguments for- or against- the proposal (which is to apply the RFC 8360
validation algorithm to today's most popular policy OID). The SIDROPS
working group definitely would benefit from more scrutiny. :-)

The purpose of the internet-draft is to have a actual proposal in hand
for discussion. The draft in its current form should be suitable for
this purpose, it points at a problem, and it describes a solution.

I am not exactly thrilled to go pound sand via a decades long
'requirements' -> 'evaluation' -> 'solutions' dance, especially since
this exact discussion already is 10+ years old. From what I understand,
no IETF tool was left unused to prevent this validation algorithm from
actually being deployed.

A call for working group adoption will make it clear whether the working
group is interested to continue discussion of the problem at hand and
the potential solution. If the working group does not wish to adopt this
document, so be it.

Even if the working group does adopt the internet-draft, I am not
certain it'll make it to the RFC publication queue. Some study and
testing is warranted. WG adoption does not equate RFC publication.

The proposal *is* complicated (just like the current algorithm actually
is quite complicated), and there are additional complications related to
whether technical debt exists (or not exists) in 'libcrypto'. At the
same time all validators already have a bunch of workarounds for
rfc3779 'libcrypto' quirks, and the APIs are diverging as years go by.

It would be my preference to focus discussion on the technical merits of
RFC 8360-algorithm and any potential positive or negative implications,
rather than focus on bureaucratic process.

Kind regards,

Job