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

[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