Re: [Sidrops] what to do when the CRL is hosed?
Christopher Morrow <christopher.morrow@gmail.com> Wed, 01 April 2020 18:35 UTC
Return-Path: <christopher.morrow@gmail.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 158213A1617 for <sidrops@ietfa.amsl.com>; Wed, 1 Apr 2020 11:35:18 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 y7fvwpfOtVZy for <sidrops@ietfa.amsl.com>; Wed, 1 Apr 2020 11:35:16 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C88CE3A1618 for <sidrops@ietf.org>; Wed, 1 Apr 2020 11:35:15 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id l25so1088728qki.7 for <sidrops@ietf.org>; Wed, 01 Apr 2020 11:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CHNaoXJYvtV6qibk7U3Tg9UKw9LXddqf9LSzSl4BPRQ=; b=I7TVOBIF2+Ey+HpbhagAdbFAnzGHZ3kbbd3Yq6+tKZpLUAfS5xWBCKIDIpXSBzctPA 6+VOjRjiul98cdS8aA3rI5soLr+XwSUEWtVHtd3HnUq4ow2gWs7x5kIaBE4oAH5fxJw4 Pc0SKrAG4MMR5BkEsZy1J/OD1o9lyVqom+dFAt0lGrmRkPd84Z0YUuo+3imRjTE9GMB4 P112sX7tzlLyd1G0spDN6NCX3rSc4IifWzynFBxkkCiNjFfCpjYbEyFIXwE4e16XMOj7 Mk2nnnxrrKJrZ/cv5AFSTEbWhmVEv4cGYLx9r7djgnyEb2zk46SOt3lIv1uWBnVrDe1i +dhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CHNaoXJYvtV6qibk7U3Tg9UKw9LXddqf9LSzSl4BPRQ=; b=MYKtugAdquYJH2oVHJpZmI669alQ9kjWvkICpk5YNDVt85tbi6v9GPuywxxyPY7I2N AMtO5MsCR1FyIZjUbIB8qZsdMLR5oLkzHyurDoT9Kfq4QIMRPuFU9m9nAAL+XfFFccxC scdQxycRRMmgrrfCC6BJo8HuFC9WGRWch8TYsOJ+S9RyBVvdTpvZgy2wl6Z97Qe0dPsP 8LIJOez7nwX7qhTQlstFrkUPJVGiyrw4PQaXdF7WX97gZUDwvh7e/OKfaQpNVNIFQ7+W spyPw3Djv4ZHSKIOBZbwE9PKoF/6u800vE3ar/82IxqXembCcRTkQUxnVhKfbnt6kuIE rYwg==
X-Gm-Message-State: ANhLgQ1UjrityVYc4Wi0s2YDEA2O2Z+3LjOYkZocmcfcjicAosKsJBz6 2I0yJ53TheVtiSdE43MpIQwbWxXkh3GYqNJi10Y=
X-Google-Smtp-Source: ADFU+vvVyVhj7qWHP8AfXMB1L3MD/IxbXIn4S44/t0nlsgCQEAFVdspAbuB69JO31J2a18mWnuoB4OErNUPOCgR/05k=
X-Received: by 2002:a05:620a:166a:: with SMTP id d10mr11664849qko.388.1585766114516; Wed, 01 Apr 2020 11:35:14 -0700 (PDT)
MIME-Version: 1.0
References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <db920115-e188-700f-ceb2-08cd2996046a@verizon.net> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> <ed15512c-4fac-f8b1-f616-4dcf7afbf396@verizon.net> <CAL9jLab_tLDwh8=thqPfWw29g+LK__T2MUfCZmLDv1v_Z77x+w@mail.gmail.com> <CAKr6gn2VN8kXB2KS5LUkuSkihoE5KqUqfD+NTLuopnTVYF1QQA@mail.gmail.com> <FBA774C0-8F96-4C47-A154-D4CA3343F892@zdns.cn>
In-Reply-To: <FBA774C0-8F96-4C47-A154-D4CA3343F892@zdns.cn>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Wed, 01 Apr 2020 14:35:03 -0400
Message-ID: <CAL9jLaaBTha6Q1AZm5V0R=-fGZMAsmAgPrcwKo3L6pvJnn1=KA@mail.gmail.com>
To: Di Ma <madi@zdns.cn>
Cc: George Michaelson <ggm@algebras.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1tHI-d95YpOMzXLuciW6iOEP0ZU>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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: Wed, 01 Apr 2020 18:35:18 -0000
On Tue, Mar 31, 2020 at 11:03 PM Di Ma <madi@zdns.cn> wrote: > > Yes. > > Although the RPKI provides object-oriented security yet the validity of an object relies on a trust chain, any wrong node of which would cause failure. > > So-called “wrong” MFT will bring about trouble no matter it is rooted from transport or RPKI provisioning side. > > Situations could be complicated as analyzed in section 2.2 of RFC 8211 in terms of adverse actions on MFT but RFC 6488 leaves much to RP to decide. > > BTW, in RFC 8211 we authors differentiate if the attacker have got access to the private key of the INR holder, trying to give a threat mode. > > So it is right time to reconsider the requirements posed on RP in case of “wrong” MFT. yes this last sentence is the discussion I'd like to see happen... I think guiding that with: "Here are the ways an manifest could go badly: bad sig, bad content, missing content, missing manifest..." and: "given the damage from X, Y, Z, the proposed actions for an RP are... because ..." > Di > > > 2020年4月1日 06:20,George Michaelson <ggm@algebras.org> 写道: > > > > I think you did capture the spirit. > > > > I would remind people that *all* the products in a repository are > > signed objects. To arrive at a state where a manifest is "wrong" > > demands two things: it doesn't reflect some real-world situation > > regarding contents of the repository *and* its signed by keys you can > > validate back to a trust anchor. If you cannot validate the manifest, > > then its not "wrong" its forged, or invalid cryptographically. To me, > > a "wrong" manifest checks out cryptographically but somehow is not > > coherent with the state of the repository. If objects are on the > > manifest but cannot be fetched, you are probably suffering either from > > hiding of objects, or a transitional state of publication. If objects > > can be found which are not on the manifest, you may be seeing > > artifacts which are not defined as critical (must be found) or, the > > manifest has not yet been updated. > > > > There are potentially transitional states in the production of a large > > repository under eventually consistent production (e.g. multiple > > asynchronous cooperating processes, dual-redundant signing models) > > where what can be fetched and what is on manifest do not align. If we > > wish to demand that the manifest and a given state of the repository > > *always* align, we need to formalise that in a way which makes it > > clear we publish repository state in as close to atomic-update as > > possible. (copying a repo to a new dir, modifying the contents of the > > new dir, and (re)publishing the change through the rename() call in > > UNIX is one such model) > > > > A missing manifest is not a "wrong" manifest -its a sign of data being > > hidden from you either because of transitional effect in publishing > > the repository, or for persisting state a problem in the repository > > (diskfull?) or, production systems, or a MITM attack. Which do you > > think is actually most likely at this current time? This is no > > different to a missing CRL in that regard. Which do you think is the > > most likely reason, because you cannot a-priori know that its a MITM > > attack, or a failure in networks, or storage systems, or production > > systems. > > > > During the early design phases of the system, we determined that since > > the products were all cryptographically signed, there was no strict > > requirement for cryptographic protections on transport. If that > > decision needs to be revised I think it should be done in standards > > work, here, as a discussion. I do not yet see a document which says > > that. I don't see formalisms which go to a normative change in SHOULD > > to MUST on this. > > > > So these comments aside, my plea is that people clearly state when > > they say "wrong" or "bad" if they mean that it is cryptographically > > valid, but does not align with some external reality, or some other > > meaning. (Which btw, is complex because the part which none of this > > can adequately capture is *intentionality* -Just because you think a > > publication of RPKI state is nonsensical does not mean its not > > intentional) > > > > Attack models need to state clearly how they acheve the state. An > > attack on the integrity of the manifest needs to explain coherently > > how it creates a manifest which checks out cryptographically, and yet > > hides or legitemates something which should not exist. They also need > > to explain how the specific attack on the manifest in these situation > > outweighs other considerations: If they have the keys, then surely the > > attack vector is to make validly signed things which cannot be > > detected as an attack? > > > > -George > > > > On Wed, Apr 1, 2020 at 1:42 AM Christopher Morrow > > <christopher.morrow@gmail.com> wrote: > >> > >> first, apologies for getting back around to this so late :( > >> > >> On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent > >> <stkent=40verizon.net@dmarc.ietf.org> wrote: > >> > >>> So, I think discussing MITM attacks is a distraction, unless we have examples of how > >>> such attacks can affect RPs in ways different from attacks on repositories. Maybe re-reading > >>> RFC 8211 would be useful, as it tries to analyze a range of possible "adverse actions" by CAs or > >>> repository managers in the RPKI context, and discusses how RPKI mechanisms are intended to > >>> detect/counter these actions. > >> > >> In the case of the incident which started this thread we ended up > >> publishing part of the content a > >> repository needs to publish such that the relying parties can verify > >> properly that the content in the > >> repository is correct/valid/usable. The discussion then went along a path like: > >> 1) "well... maybe we shouldn't have belt and suspenders?" (manifest AND crl) > >> 2) "what happens if we don't publish this pesky CRL? and rely only > >> on the manifest?" > >> 3) "what if we don't publish the manifest and only rely on the CRL?" > >> 4) "CRL + Manifest has made 'rp software' hard/buggy" > >> > >> In the world where the protections specified for RPKI exist: > >> 1) self contained content protection (roa / ee-certs / etc are > >> packaged securely) > >> 2) crl signed and available in the repository for revocation actions > >> on objects in the repository > >> 3) manifest signed and listing all objects of interest in the repository > >> > >> Steve (kent!) is right mitm is harder to see as a threat. > >> "All objects you get are signed by a ca-cert which is signed by the > >> root.. which is in the list of TAL you have. You can't have missing > >> objects and you cant' remove objects without affecting the signed > >> manifest" > >> > >> In a world where we remove one/some of the protections: > >> A) no more manifest > >> B) no more crl > >> C) both > >> > >> I think mitm problems are much harder to detect/deal with :( > >> It sounds like WG folk (RP users and RP/CA software authors) are > >> asking for guidance on handling the problem(s) discussed here. > >> It sounds, to me, like a chat at the upcoming interim meeting would be > >> a great place to start that with some slideware and a proposal to use > >> as kindling. > >> > >> I think the shape of the conversation is roughly: > >> "What would be the effect (on the routing system) for RelyingParties > >> if we decided to be less strict about CRL existence?" > >> "What would be the effect (on the routing system) for Relying > >> Parties if we decided to be less strict about repository contents vs > >> Manifest contents?" > >> "What happens to the routing system if the manifest and crl are > >> either/both 'broken' in a repository?" > >> > >> I don't think it matters much to the routing system where the breakage > >> occurs (my repository or RIPE/ARIN/etc) certainly there's more fallout > >> from ARIN/RIPE/etc, but... you can't get to me either way :) > >> (possibly) until repair and propogation. > >> > >> Thoughts on some slideware and discussion? > >> Did I about capture the meat of the sandwich here? > >> > >> -chris > >> co-chair but asking as a regular chemical engineer at this party. > >> > >> _______________________________________________ > >> Sidrops mailing list > >> Sidrops@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidrops > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > > > >
- [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Jared Mauch
- Re: [Sidrops] what to do when the CRL is hosed? Francisco Javier Moreno Arana
- Re: [Sidrops] what to do when the CRL is hosed? Ben Maddison
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Martin Hoffmann
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? George Michaelson
- Re: [Sidrops] what to do when the CRL is hosed? Louis Poinsignon
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Christopher Morrow
- Re: [Sidrops] what to do when the CRL is hosed? George Michaelson
- Re: [Sidrops] what to do when the CRL is hosed? Jared Mauch
- Re: [Sidrops] what to do when the CRL is hosed? Randy Bush
- Re: [Sidrops] what to do when the CRL is hosed? Di Ma
- Re: [Sidrops] what to do when the CRL is hosed? Oleg Muravskiy
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Robert Kisteleki
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Robert Kisteleki
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Nathalie Trenaman
- Re: [Sidrops] what to do when the CRL is hosed? Claudio Jeker
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Robert Kisteleki
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Rob Austein
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Martin Hoffmann
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Oleg Muravskiy
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Christopher Morrow
- Re: [Sidrops] what to do when the CRL is hosed? George Michaelson
- Re: [Sidrops] what to do when the CRL is hosed? Di Ma
- Re: [Sidrops] what to do when the CRL is hosed? Christopher Morrow
- Re: [Sidrops] what to do when the CRL is hosed? Christopher Morrow
- Re: [Sidrops] what to do when the CRL is hosed? Robert Kisteleki
- Re: [Sidrops] what to do when the CRL is hosed? Robert Kisteleki
- Re: [Sidrops] what to do when the CRL is hosed? Martin Hoffmann
- Re: [Sidrops] what to do when the CRL is hosed? Claudio Jeker
- Re: [Sidrops] what to do when the CRL is hosed? Job Snijders
- Re: [Sidrops] what to do when the CRL is hosed? Christopher Morrow
- Re: [Sidrops] what to do when the CRL is hosed? Jay Borkenhagen
- Re: [Sidrops] what to do when the CRL is hosed? Randy Bush
- Re: [Sidrops] what to do when the CRL is hosed? Lukas Tribus
- Re: [Sidrops] what to do when the CRL is hosed? Randy Bush
- Re: [Sidrops] what to do when the CRL is hosed? Martin Hoffmann
- Re: [Sidrops] what to do when the CRL is hosed? Lukas Tribus
- Re: [Sidrops] what to do when the CRL is hosed? Tim Bruijnzeels
- Re: [Sidrops] what to do when the CRL is hosed? Robert Kisteleki
- Re: [Sidrops] what to do when the CRL is hosed? Martin Hoffmann
- Re: [Sidrops] what to do when the CRL is hosed? Stephen Kent
- Re: [Sidrops] what to do when the CRL is hosed? Randy Bush