Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Thu, 16 April 2020 17:43 UTC

Return-Path: <stkent@verizon.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 9D8FA3A09A4 for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 10:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 FRbZCRrsVwte for <sidrops@ietfa.amsl.com>; Thu, 16 Apr 2020 10:43:52 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 E74EC3A09A2 for <sidrops@ietf.org>; Thu, 16 Apr 2020 10:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1587059031; bh=u5Cws9G4KxXYP+uQgcC+X8uwoKwbHsY0LjC8B2Jz7j8=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=RsYc1vxs++fkN8fKXE5C+GW0t7+PH42k1GD1bLoVckUZb9Tm5aiTQFuZtO32PZaY0fMN8cNTCXCPDrwYmDexbS75TKhnROnkJN30MgeAY6zZ4O/L2LNBb0dlD8CVdnWN7nyHVxpyJIgw2cQgu0I/7aplzBq/HhcR2wtr2naSACsT/Stf1ogw+6+o/frZOLT1xzSu3eBBy96X7zUf6YZB0dAga4gKYTGF/O3/Fb8LJJI25BmpuXiJ4Lk2bXT29osd+IPSXLg7UhU3flg8quQFpcz6dQnWO/eedsyfkQqpsva6KRzCT+Db4YmsYJlH7wxuOCK8p7pU4NNLRVN1Gq20jA==
X-YMail-OSG: Q_SH6FIVM1ktYZvT4j9G5ieymxkTLlKDRr1G5YdtxhItizzHyiEEXdxE_SvQO.5 Qibexs7EOGAZDLWyVF4PdBCZ2DuGQQHVVSlRdBbxqd5x3TM6rDsYMHMl..seWdh2G.0Lgcyaxr0Q EipLcv4NIrSLS8HtQYlAJNGhdQWYRtg8TYdgCbRvrixmMdimj5rKRF1oXJq3k5cjXaliTUB07K.o 5gl1odniMDVYOkSf3e6ZFeGmqe8di4KkpZX.26JvwwG9bsCysHByWTczXCUL60fF8RlfeGMj9ZvJ DDYvJKW34GmcLj4d0H8hzd_hnw19CbIISXQZUOdPIxZrRexZqCXI.JxbjI8ceuDxgIw8zlSFkrgL i3zFyzGznJqTqoQ1XiLeoE0paV8pLSTKVus6wD7jdn03jXMICNwN9UsrL1PJndN4LlMClIwjOS4. e8t7Ex5UCI1gmN68kI0roPKvXJPVPU4f4IRT_n3O67fGxqOCvAbejVSuXyKTrLVsLYesJ55yYdjM 56He.E0RkMNjrSjcpy3lTEKp3kJgVEF_306I3VA0LUxyXdwQmaMY0jx5rvRlN8G3Yb3AvhZsYo3T o6c_RePH.kzrY80fTs06k_mqzO7cwW6ivGQrraGi66LgLrcXAw.y6.5uxmGkB2E5GtxaCH.Ptl9b vrAhy9jtxMIBj2t3pxqfZP7hkz_VdxxQbGqY5KHfykLClD3oUFsDu84jJNBban8.1NDbLP0fB_Yl G6WGJEBNOwOYTOsoYpXcNx7Sz3GPavYG1VT1nLVs5JgQO2mQj9byv_ILBKoJ93iq4KpyhecuJqH5 VRzoFVE6DSUIomWTuxxVUeXRkOkk4KDhUFKZTJnArzT0ZRznsvOaX.L7yxS2qO2Vt2zwBD1McBHS Je7wwXo0CWtlm7ixkZLtjasrKShFn6_QKSTaqzonljVMIZgMvi25oZINZSRElfZGWqHIvTQNCQDJ TR0q3ehXjsCY67pW1aPz7GH_CgY8lU7Vv6vmhQEzygZO46Qoc90kkYvdHzybpV5xShKEa8uIrPnb Ahcg.MhgTGqcSi_.G9ajeQfEqWyvC5ovzX3amrFHTelw9S5ljXLsMuBBfIdLMjseAkrOsuKBKsQi yyGizsgjRUlbvF4IHnZmYG8mxPfNDDFXY8o_ElTfmhZ.MZim1wy4_S0BeZKYjyV.MRlAWXWQ05Yw 5fNwLXkKTuLIhPsRcmqYls6U.S3RhqwXojFW4MOerGdevKQUnetSez4lQXI18gcfXN15XGupy.nv Io9M.Cm7RWih3Nm9jnd_kjBttw1xz4Hy29YLOW._2kHGz9JhvAwnbaZOw6ingtvLsn8KpIZbAs08 4dRIotPRfGeTws5aRSGMLsxCxMV_a7717HhFyqX2F0J_lCYgRyo9BrvC0SiWIVzK8R2o54G1bYZ5 3qj2ddcTCRjoVW8wVCWWKrGiA5D5.XllXcxn9k8uNPnDtpMIpAp3K.FwP3oRz1OhI3Dis6Bw-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Apr 2020 17:43:51 +0000
Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID efcd595bc35b2a6470e5a9c56ed98242; Thu, 16 Apr 2020 17:43:46 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: Martin Hoffmann <martin@opennetlabs.com>
Cc: sidrops@ietf.org
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200415150141.016d021d@glaurung.nlnetlabs.nl> <e7f329ae-4878-2311-a61f-15946cb46a39@verizon.net> <20200416175326.3f04db80@glaurung.nlnetlabs.nl>
Message-ID: <123646a7-e1d5-e939-53fe-21f3326e79be@verizon.net>
Date: Thu, 16 Apr 2020 13:43:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200416175326.3f04db80@glaurung.nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/HQ8e2pCinZMCqBy1fjPQnF9LfHc>
Subject: Re: [Sidrops] trying to limit RP processing variability
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: Thu, 16 Apr 2020 17:43:54 -0000

Martin,
> ...
>
> That wasn’t quite the case I was thinking of (although I think this is
> a case worth calling out specifically to avoid confusion), but rather
> a case where say, a ROA’s EE certificate contains a URI for the CRL
> Distribution Point that is referring to a CRL that is not listed in the
> issuing CA’s manifest.
This would be an error by the CA. RFC 6480 notes where the CRL is 
supposed to live in the repository system.
> So, when validating the EE certificate of a signed object, the CRL
> could be missing in the manifest and it could be present in the
> manifest but missing in the sense that it can’t be downloaded from the
> publication point.
>
> I think this is a case worth clarifying since it seems to currently be
> left to local policy.
I'm all in favor of reminding folks that there are a lot of details that 
an RP has to check, which is why Di Ma and I co-authored the 
recently-approved Informational RFC on this topic. This  is an example 
of a CA not following the requirements established in one of the many 
applicable RFCs, and I suspect we may have failed to cite this in the 
document in question.
>>>      1.Manifest present, valid, current
>>>
>>> If there is a present, valid, and current manifest, the CRL can
>>> safely be ignored for all objects.
>> Tim has suggested that, but to do so would make the RPKI not
>> consistent with RFC 5280.
> I’m not sure. In section 6.1.3, RFC 5280 says
>
> |  (3)  At the current time, the certificate is not revoked.  This
> |       may be determined by obtaining the appropriate CRL
> |       (Section 6.3), by status information, or by out-of-band
> |       mechanisms.
>
> Determining certificate revocation via lack of presence on a manifest
> could be construed as an "out-of-band" mechanism.
This part of 5280 is designed to accommodate OCSP as a revocation status 
distribution mechanism, something that was not part of X.509. The RPKI 
requires CAs to publish CRLs, and it states where the CRLs are to be 
published in the repository system (RFC 6480).
> ...
>>> Presumably this chould only be limited to objects of the same type,
>>> i.e., if there is a least one missing, corrupted, or invalid ROA,
>>> discard all ROAs.
>> I'm not sure why the group-oriented approach is useful, expect
>> perhaps for ROAs. Why would one elect to ignore some router certs if
>> one were missing?
> Hm, true. So perhaps this should be defined per object type? For ROAs
> (and in the future ASPAs) partial sets cause hard to debug issues
> whereas for router keys and ghostbuster records, having to discard
> single objects of a set shouldn’t cause any harm.
That sounds like a good argument.
>
>>> If the aim is to avoid risking accidentally marking routes as
>>> invalid, this should probably also extend to all information
>>> published by child CAs.
>> is the concern here that ROAs issued by a subordinate CA might be
>> treated differently if there is a missing ROA associated with the
>> parent?
> I was thinking of the possible case that the parent issues a ROA for a
> resource but also delegates it to a child CA which then issues
> additional ROAs for the same resource. If the parent ROA is missing,
> you cannot rule out that the was indeed the case, so in order to be
> safe, you’d have to discard all ROAs for prefixes associated with the
> parent.
So, the parent issues a ROA binding a range of addresses to an AS that 
the parent holds. But then  the parent delegates the same range to a 
child, which is free to bind the addresses to a different AS (that the 
child holds). Thus a route advertising either AS as the origin is valid. 
If the parent's ROA is missing, the AS bound to it is no longer 
considered valid, but the child's ROA is. So, why does one have to 
discard/ignore all other ROAs associated with the parent?
>
>>>> 3.Manifest present, but invalid
>>> The entire PP is ignored.
>> So, it's OK to ignore a CRL that is invalid, but not a manifest.
>> Personally I believe that if a CA cannot manage to correctly generate
>> both a CRL and a manifest, it has a serious operational problem.
> Indeed. However, bugs exist and unexpected things have a tendency to
> happen. I still fail to see how, given a strict adherence to the
> manifest, the CRL provides additional value for objects published
> within the RPKI repository. So for robustness, it may indeed be
> preferable to remove this additional possibility for breakage.
As I noted in my reply to Tim a while ago, if we want to view the 
manifest as the only critical determinant of whether a cert is revoked, 
then why bother checking the validity interval for the EE certs? Why not 
just say that if an EE cert is listed in a manifest by a a CA, then the 
CA is declaring it to be valid, period? One can argue that remembering 
to reissue certs with new validity intervals is also a burden for a CA 
and creates another opportunity for the CA to post inconsistent info at 
a PP.
>
>>> This essentially ignores the CRL for any object published within the
>>> repository and essentially moves its role over to the manifest. The
>>> CRL would still be considered for objects published outside the
>>> repository, such as the proposed Resource Tagged Assertions.
>> A missing manifest is a serious concern, but I would consider using
>> cached, still valid objects for the PP, and insisting on contacting
>> the CA or PP maintainer.
> If the manifest takes over the CRL’s responsibility of expressing
> revocation, you’d open a window to replay revoked objects. So this
> translates to the question: What would you do today for a stale or
> missing CRL?

I don't understand your example. If a manifest trumps a CRL, then 
revoked objects would not appear on a current manifest and so replay of 
such objects would be ignored, right?

Steve