Re: [Sidrops] feedback on draft-michaelson-rpki-rta

Job Snijders <job@fastly.com> Tue, 02 February 2021 15:57 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 E8C163A1BE3 for <sidrops@ietfa.amsl.com>; Tue, 2 Feb 2021 07:57:13 -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 55Ie6_shyzUl for <sidrops@ietfa.amsl.com>; Tue, 2 Feb 2021 07:57:12 -0800 (PST)
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 E35273A1C79 for <sidrops@ietf.org>; Tue, 2 Feb 2021 07:57:04 -0800 (PST)
Received: by mail-wr1-x444.google.com with SMTP id v15so21043169wrx.4 for <sidrops@ietf.org>; Tue, 02 Feb 2021 07:57:04 -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=3cxFw4J3uYAvDsvkhcNssDltARZXHKsySAQd9yVukPA=; b=wyprcMzTOnw3NrBC9QcUNrT3WQ4D3yAV/yLHq+vuOIuULTubPU58GBkdQUFXaDr74x caDmE2nhTglzAL7olw0Gf2Rc/N6Hxx6GUzDN3lEdum/3ZxxnjI0MKlqBNXqyMd6ddmqE W4XMWHP7fV2yuBlAv5yNBnhTv9dTDczH+ikP8=
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=3cxFw4J3uYAvDsvkhcNssDltARZXHKsySAQd9yVukPA=; b=ePgJqgZ/wwERvu4KEKSwi/mZRJVhW5bI3VvFcSsZDfg340lcITd926/R1f+XvqVDa5 o1I9kqvQsPBAUykc18xQ9bQ+EkBw39h1Y12c2Mf4a56T+Fb9GhuhXeV4AWiSaqX2JlLL zcyTAWhJfecILvJH8eFqfrtwLy0AHyV/pvHKO11RX+A+0SK0Cv5M03y3Qg6Jv6MC/2m6 bGtBQleQ+n2LK0uTdcmJD9D30ZFNDzUe+l1UrcnMa43zL12wGCKtYyOsN6l5Iyrn957x k6EWez1AWhe5mLMWDKp9sVwmmP7MYu+0vmPbpw+KhvxGbBg8vNyDcnm1Ga3y9Um5uDjJ CZUA==
X-Gm-Message-State: AOAM533GLRwHHF/xYnOJJwp5Fy563ccqTcO/mfWmIrb2CKGmWHICw4ei RK7JhEvdhGA1W6WExF+FWyEzcMKTdHHPosSMUL5J+/tzWwenaXNkryrV/H6ffgLo/qpcKxXipH6 ZfQd0AeGtU4zzJZ9iPIa5mQONjtkanfp8Ho+bxRBbu7xlIU0+qN/BdtdoQg==
X-Google-Smtp-Source: ABdhPJxqcscsuEQdisNl6Or2WVvVc0zFdlH2HH3BH5fJU/B7JUgk8VhXEYPOe+r8VlbbRwXXSXIVVw==
X-Received: by 2002:a5d:50c1:: with SMTP id f1mr24960910wrt.235.1612281422789; Tue, 02 Feb 2021 07:57:02 -0800 (PST)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id t8sm3445258wmq.36.2021.02.02.07.57.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 07:57:02 -0800 (PST)
Date: Tue, 2 Feb 2021 16:57:00 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <YBl2TH9FiBf6iKFt@snel>
References: <20201229101412.GA56136@diehard.n-r-g.com> <X+scpsd6kDQ72nLa@bench.sobornost.net> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <X+tR06kF3aPZ4+18@bench.sobornost.net> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <20210112145800.nocjbd4millmbx4i@benm-laptop> <X/31sdsc/ZzGDsjf@bench.sobornost.net> <CAKr6gn3z_N=xGbScwe3xTUxbqWwySwAkncSbm0KKyDZjwVucOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKr6gn3z_N=xGbScwe3xTUxbqWwySwAkncSbm0KKyDZjwVucOA@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/GMhJKtHVjcSpg1aPZtStFj753Sw>
Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta
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, 02 Feb 2021 15:57:14 -0000

Dear group, authors,

I've consulted with various subject matter experts, and at George's
request I again reconsidered. Unfortunately I could not arrive at a
different conclusion about the current RTA proposal, it is too
complicated for me to support. It appears I'm not the only one
questioning the current RTA approach:

Tim offered a very insightful and honest write-up [1], I'll cherry-pick
from what he and others wrote:

     "It is true that requiring single signing for RTAs simplifies the
     specification."

Stephen Kent states [2]:

    "Your characterization of the added complexity and validation
    failure possibilities is worrisome"

Fredrik Krosback says [3]:

    "we do not know the full extent of which software is out in the wild
    that may or may not need full refactors to handle this."

Rob Austin on RFC 6488 (August 2010) [4]:

    "As an implementor I really want to use a common code path to
    validate the common portions of all objects of this general form,
    and would really prefer a single specification of what that code
    should do. :)"

Richard L. Barnes (August 2010) [5]:

    "This document (red: RFC 6488) seems like a good approach to
    maintaining some sort of long-term architectural sanity in the RPKI,
    maybe even something that could simplify tool-building."

For rpki-client (and I suspect FORT and OctoRPKI too) the above
statements hold true: I think single-signer RTA can be implemented in a
relatively short span of time (repurposing existing code such as the ROA
codepaths). On the other hand multiple-signer requires significant
refactoring. As for the suggestion to just not support RTAs produced by
multiple-signers: I'm not comfortable with latent capabilities, this is
security orientedd software after all. Today's latent capability is
tomorrow's landmine.

So... if the authors wish to deviate from RFC 6488, are they willing to
do the real legwork and write 6488bis to change the below part?

    "Additionally, the SignerInfos set MUST contain only a single
    SingerInfo object"

If the authors really wish to continue RTA with the innate ability for
multiple signers within a single RTA object, I'll step out of the way.
Endless bickering does not help us here.

However, I hope there will be understanding if I spin up a 'competing'
draft to address a similar solution space as RTA covers, this time in
full compliance with RFC 6488. OIDs are cheap and the market usually
favors simplicity.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/pSIibdv-x7NgV1D9tDBx1HvYTTo/
[2]: https://mailarchive.ietf.org/arch/msg/sidrops/gx5SQI8DzRFnU2DZrZdH6rdW8Tc/
[3]: https://mailarchive.ietf.org/arch/msg/sidrops/hNKSvMFXIQzbH5TsiDgFqy-lqpE/
[4]: https://mailarchive.ietf.org/arch/msg/sidr/Zo3Hg1AwqqUi4tD1fWmd2aqTANU/
[5]: https://mailarchive.ietf.org/arch/msg/sidr/esWy85UvfjvO7N95pfZHBYQGOVY/