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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
