Re: [sidr] preventing SKI collisions

At Wed, 7 Oct 2015 09:22:40 -0400, Sean Turner wrote: > > On Oct 06, 2015, at 08:30, Sandra Murphy wrote: >> On Oct 5, 2015, at 4:36 PM, David Mandelberg wrote: >>> >>> 4. Add text warning relying parties to detect malicious CAs that >>> cause too many

Re: [sidr] preventing SKI collisions

> I'd prefer a warning in the security considerations section and a > recommendation to alert the operator. please. and put this to bed already. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] preventing SKI collisions

Speaking as regular ol’ member only. On Oct 5, 2015, at 4:36 PM, David Mandelberg wrote: > On 2015-09-16 10:38, Sean Turner wrote: >> Okay so I think we’re in agreement here that we don’t work on #3 now, >> but I’m also thinking that we should leave #1 and #2 alone for

Re: [sidr] preventing SKI collisions

On 2015-09-16 10:38, Sean Turner wrote: Okay so I think we’re in agreement here that we don’t work on #3 now, but I’m also thinking that we should leave #1 and #2 alone for now. If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then it sounds like it's also good enough for BGPsec.

Re: [sidr] preventing SKI collisions

On Aug 11, 2015, at 12:12, Richard Hansen wrote: > Unfortunately no, with the disclaimer that I haven't really thought > about it in depth. Because of the challenge of accomplishing topic #3, > I would like start with the much simpler topic #1. Note that I'm not > opposed to

Re: [sidr] preventing SKI collisions

>> Unfortunately no, with the disclaimer that I haven't really thought >> about it in depth. Because of the challenge of accomplishing topic #3, >> I would like start with the much simpler topic #1. Note that I'm not >> opposed to tackling #3, but the amount of work involved means that I'd >>

Re: [sidr] preventing SKI collisions

Richard, no problem. anyway, my comments may have been too strongly worded. If we feel that it's important for router certs to use a different hash alg, then the router cert profile can define which alg to use, as an explicit, profiled deviation from the RPKI cert profile. We can also

Re: [sidr] preventing SKI collisions

(I see there’s been some more mail on this thread so hopefully I won’t contradict myself later :/ ) No fear about harming SHA256 deployment! We’re already using it for the hash+sigs of the Manifest, ROAs, RPKI-certs (both for RPKI and BGPsec). On Aug 06, 2015, at 20:33, George Michaelson

Re: [sidr] preventing SKI collisions

Saw you’re earlier msg, but figured I’d just reply to this one. On Aug 07, 2015, at 12:07, Richard Hansen rhan...@bbn.com wrote: On 2015-08-07 06:35, Randy Bush wrote: This change would require certificates to be re-issued (or possibly keys to be rolled) all the way down from Trust Anchors.

Re: [sidr] preventing SKI collisions

On 2015-08-11 13:09, Sean Turner wrote: Saw you’re earlier msg, but figured I’d just reply to this one. On Aug 07, 2015, at 12:07, Richard Hansen rhan...@bbn.com wrote: On 2015-08-07 06:35, Randy Bush wrote: This change would require certificates to be re-issued (or possibly keys to be

Re: [sidr] preventing SKI collisions

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

Re: [sidr] preventing SKI collisions

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

Re: [sidr] preventing SKI collisions

Hi Sean, Specifically on this point: On Aug 7, 2015, at 12:52 AM, Sean Turner turn...@ieca.com wrote: I’m all for switching to using a better hash algorithm to avoid collisions, but why can’t we just do it anytime we want? The SKI/AKI fields are only ever generated by a CA so the RPs

Re: [sidr] preventing SKI collisions

This change would require certificates to be re-issued (or possibly keys to be rolled) all the way down from Trust Anchors. When the parent CA re-issues a certificate for the child CA with a new style SKI, then the child will have to re-issue its products with a new AKI. This is not

Re: [sidr] preventing SKI collisions

On 2015-08-07 06:35, Randy Bush wrote: This change would require certificates to be re-issued (or possibly keys to be rolled) all the way down from Trust Anchors. When the parent CA re-issues a certificate for the child CA with a new style SKI, then the child will have to re-issue its products

Re: [sidr] preventing SKI collisions

On Aug 7, 2015, at 11:35 AM, Randy Bush ra...@psg.com wrote: This change would require certificates to be re-issued (or possibly keys to be rolled) all the way down from Trust Anchors. When the parent CA re-issues a certificate for the child CA with a new style SKI, then the child will

Re: [sidr] preventing SKI collisions

On May 22, 2015, at 10:55, Richard Hansen rhan...@bbn.com wrote: Hi all, A while back Sean Turner raised the idea of switching to SHA-256 for the Subject Key Identifier while discussing rfc6487bis (see http://article.gmane.org/gmane.ietf.sidr/6878). I see a couple of reasons to do this:

Re: [sidr] preventing SKI collisions

Can you give me some indication at what level of operation a SHA1 over the public key risks colliding? 0.001? 0.1? I don't want to impede progress if SHA256 is sensible, but I have a feeling this is a risk almost at the noise floor. Since its per-CA, the CA is presumed to have to hand a

Re: [sidr] preventing SKI collisions

On 2015-08-06 19:52, Sean Turner wrote: On May 22, 2015, at 10:55, Richard Hansen rhan...@bbn.com wrote: Hi all, A while back Sean Turner raised the idea of switching to SHA-256 for the Subject Key Identifier while discussing rfc6487bis (see

Re: [sidr] preventing SKI collisions

Richard, Thanks for thinking (in great depth) about the potential security implications of SKI collisions in BGPsec. In the general case of a PKI, collisions of SKI values are not security relevant. The SKI MAY be used in path discovery, but the intent was to limit its use to quickly

[sidr] preventing SKI collisions

Hi all, A while back Sean Turner raised the idea of switching to SHA-256 for the Subject Key Identifier while discussing rfc6487bis (see http://article.gmane.org/gmane.ietf.sidr/6878). I see a couple of reasons to do this: * If/when additional weaknesses are found in SHA-1, 3rd party