Hi Demian,
On Jan 23, 2014, at 1:46 PM, Demian Rosenkranz <[email protected]>
wrote:
> Hi,
>
> I'm thinking about another potential DoS attack. An entity which owns a CA
> certificate has the possibility to generate a huge hierarchy of further CA
> certificates without any limitation (as far as I know).
>
As far as I remember there are no formal restrictions regarding either the
number of child CA certificates issued by a CA, or the length of the chain.
> In contrast to the generation of a huge amount of ROAs, this attack isn't
> limited regarding the number of objects/certificates.
>
> I.e. a compromised/bad entity owns a /16 prefix and generates 10000 CA
> certificates and hand down this prefix until the lowest CA certificate and
> generates 2^8 ROAs, a relying party software would be forced to check this
> hierarchy 2^8 times.
Some say that the same resource 'should' not appear on multiple child CA
certificates, however in practice this can happen in case of a child key roll,
and a make-before-break resource transfer. There is no notification about the
reason, so RPs have a hard time guessing. In short: our RP doesn't care about
resources appearing on multiple child CA certs. If the certificates are valid,
the duplicate resource is valid for both branches.. if the parent disagrees,
they should revoke / re-issue as needed.
That said, if one wants avoid duplicating resources in an attack like this
there is always IPv6.. And then it's of course possible that it wasn't intended
as an attack at all, but some over zealous CA goes granular way beyond present
day BGP --- eg. giving ghostbusters to all their v6 end users ;)
> Of course, this is kind of a blunt attack but without making any provisions,
> this "local cache flooding" could lead to a disturbance of all (worst case)
> local caches for a certain time. Some smaller RP could be slower in remedying
> this.
While I don't think we have formal restrictions, I can imagine certain
mitigations if this would become a serious threat:
= Parent of the offending CA could revoke the certificate (if abuse is defined
in terms of use, talking doesn't help, etc.., reactive by nature though)
= RPs could limit the maximum length of the cert chain, or even number of CA
certs issued by CA certs they are willing to accept
- e.g. pro-actively quarantine 'spam-CAs' like this, and allow the
end-user to override
- or re-actively.. proceed, but warn and allow user to disregard
- or a mix of both of course with some thresholds, prob. allowing the
RIRs to issue a bit more
= RPs should probably employ strategies to ensure that a lot of work in one
part of the tree does not block validation of the remaining tree (if resources
don't overlap).
> Are there any restriction to this attack I've missed? Any feedback is very
> welcome!
I would say that been though it's entirely possible to attack the rpki by
producing many objects, it's not feasible to do this *covertly*. This will get
get you noticed, quickly.
So while I see the value of thinking about these scenarios and possible ways to
mitigate them - thank you :) - I am not convinced that we should go overboard
in terms of best practices for RPs, or general restrictions for CAs, at this
time. I would consider possible *covert* attack vectors on the rpki
infrastructure to be much more serious though.
Cheers
Tim
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
