Re: [sidr] preventing SKI collisions

[Richard Hansen <[e-mail]>]

On 2015-08-11 15:48, Stephen Kent wrote:
> Sean,
> 
>> ...
>> Okay so I want to agree.  But, I’m still trying to grok something
>> you sent in an earlier msg
>> (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI)
>> that I think is related when you said:
>>
>>   RPs would not have to calculate/validate the SKI value; they would only
>>   need to check for collisions within an AS.
>
> No, and yes.
> 
> I was chatting with Sandy and noted that a compliant RP does have to 
> check that the SKI is the hash of the public key, as per RFC 6487.
> That RFC says that KI values are computed as SHA-1 hashes of the
> (relevant) public key (section 4.8.2), and that RPs are supposed to 
> confirm this, as per item #3 in Section 7.2:
> 
>           The certificate contains all fields that MUST be present, as
>           defined by this specification, *and contains values for
>           selected fields that are defined as allowable values by this
>           specification.*
> 
> This requirement is more stringent than what 5280 mandates. 5280
> imposes requirements on CAs wrt cert generation, but does not require
> that RPs verify that a CA has adhered to these requirements. This
> one-sided approach has not worked out well in the PKI arena in
> general, which is why the RPKI adopted a more symmetric model, i.e.,
> specify what each CA is supposed to do, and then have every RP verify
> that the CAs are doing what they are supposed to.

Yes, you're absolutely correct.  I hadn't noticed that requirement until
both you and Sean quoted it today.

I did not intend to imply that RPs can or should stop validating the SKI
value if the proposed change was accepted.  Indeed, I think it is a good
idea to require a strong hash algorithm and to require RPs to validate
the value.  What I meant to say is:

    If the proposed change was accepted, the ability to defend against
    the attack would no longer depend on validating the SKI; merely
    identifying and invalidating certs in an AS with colliding SKIs is
    sufficient.

Similarly, when I said the following in
<http://article.gmane.org/gmane.ietf.sidr/7119>:

    The above procedure does not require RPs to compute the SHA-1
    hash, yet it's secure against an attacker who wants to create
    colliding certs to overwhelm routers with computational work.
    This validation procedure would enable CAs to use a simple counter
    or any other algorithm for the SKI value because the RPs wouldn't
    be validating the SKI.  That's OK -- the security of BGPsec would
    not be compromised (I think).

I didn't intend to imply that we should stop validating the SKI or
switch to a weak algorithm, only that if we did so then I believe that
the security of BGPsec would remain intact (assuming we adopted the
proposed change).

With apologies for the confusion,
Richard