Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))

["Osterweil, Eric" <[e-mail]>]

He Sandy,

Speaking just as a regular ole wg member:

The issue Danny alluded to is NOT private keys in rpki. It is the fact that the specs imply that routers that need to sign updates ON BEHALF OF ASES need to do so with private keys that have been vouched for. But getting these private keys "onboard" routers that lie across (for example) foreign borders can be an operational nonstarter. For ex, if my router's key needs to be voched for but its private portion (that signs updates) is sent over a medium in which it can be intercepted, then how can I trust the signatures from it. Conversely, if I cannot securely get my private keys onto my routers across potentially hostile borders, how can I expect them to sign my AS' updates?  

His point is NOT addressed by any draft in the wg (since you asked).

Hth,

Eric


----- Original Message -----
From: Murphy, Sandra [mailto:[e-mail]]
Sent: Friday, May 04, 2012 06:24 PM
To: Danny McPherson <[e-mail]>; Christopher Morrow <[e-mail]>
Cc: sidr wg <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))

still speaking as regular ol' member

Looking back, I do not see a reply from Danny to my question below.

But the subsequent conversation reads to me like "onboard .. signing certificates" means getting the private keys routers would use for signing into the routers.

Because the below implies that the "signing certificates", i.e., private keys, would be "from the RPKI", I figure I'd better speak up.  Just in case someone actually thought that was being suggested.

Communicating the router's private keys in the RPKI would be a bad idea.

First, of course, is the confidentiality concern.  Private keys are supposed to be protected from exposure.  Creating RPKI objects where they would be protected from exposure would be hard.

Furthermore, the private keys used in the routers are strictly a local concern.  There is no need to communicate them globally.  So publishing them in the RPKI at all, even if protected, would be a poor choice.

I do not know that anyone plans to use the rpki-rtr protocol to get private keys to the router.

--Sandy, speaking as regular ol' member

________________________________________
From: [e-mail] [[e-mail]] on behalf of Murphy, Sandra [[e-mail]]
Sent: Wednesday, April 11, 2012 1:28 PM
To: Danny McPherson; Christopher Morrow
Cc: [e-mail]; [e-mail]; sidr wg
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

speaking as regular ol' member

On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [[e-mail]] said:

>From there, we can discuss the issue of, for example, HOW TO onboard
>and purge signing and validating certificates to routers from the RPKI --
>[I suspect the intention was to use rpki-rtr protocol for this, but it doesn't
>currently support it, nor are the security implications clear].

I can not  understand your comment.  What do you mean by "signing certificates"?

I can guess that "validating certificates" means the certs carrying public keys used to validate signatures, but the "signing certificates" part has me stumped.

--Sandy


________________________________________
From: [e-mail] [[e-mail]] on behalf of Danny McPherson [[e-mail]]
Sent: Tuesday, April 10, 2012 9:15 PM
To: Christopher Morrow
Cc: sidr wg; [e-mail]; [e-mail]
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:

> yes, my goal was to have updated the wiki today at the office, work
> intruded... tomorrow I'll do that with some more content for each
> item, and hopefully better coordinates as well for the location.

Thanks.

>> Also, are we collecting requirements for these (e.g., object scale, RPs, etc..)?  Basing these discussions on requirements that exist somewhere already?  Or simply discussing solutions that have already been developed and deployment experience?  If the latter, then we can we ensure we reference and prepare to discuss what requirements drive to the development of those solutions?
>>
>
> I think the only bit in the 3 that has a current 'requirements'
> discussion is the 'freshness' (item 2). The first item 'deployment
> discussion' is really a discussion of:
>  "Should there be some document that describes the top N (3?)
> deployment scenarios && where should that document/presentation/etc
> live?" (I suppose implicit in that is 'requirements for format,
> content, intended audience')

I was thinking more simply along the lines of "a fully deployed RPKI today would have o objects and r RPs a c churn and we ought to ensure our designs accommodate that" -- only then can we have a reasonable discussion on, e.g., data freshness?  What have we based these design goals on thus far - do we have a stable reference for this?

>From there, we can discuss the issue of, for example, HOW TO onboard and purge signing and validating certificates to routers from the RPKI -- [I suspect the intention was to use rpki-rtr protocol for this, but it doesn't currently support it, nor are the security implications clear].

Only when we get to that point will we really begin to understand the dynamics of RPKI and it's employment for secure routing (well beyond "authorized" origin policy configuration), and the impact of rate+state in both the RPKI and it's effectuating in the routing system, and perhaps most importantly, the inter-dependencies between the two (even basic stuff like the rate of updates from an RPKI cache to a router in a fully loaded system given today's RPKI object counts).

>> Also, it looks to me like we're in dire need of a charter update...
>
> for which? (I didn't think that any of the 3 items was actually
> outside of the current charter)

I meant the goals and milestones, apologies for not being clear.

-danny
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr