Re: [Sidrops] what to do when the CRL is hosed?

[Di Ma <[e-mail]>]

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. 

Di

> 2020年4月1日 06:20，George Michaelson <[e-mail]> 写道：
> 
> 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
> <[e-mail]> wrote:
>> 
>> first, apologies for getting back around to this so late :(
>> 
>> On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent
>> <stkent=[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>