From: "Osterweil, Eric" <eosterweil@verisign.com>
To: "'Sandra.Murphy@sparta.com'" <Sandra.Murphy@sparta.com>,
 "'danny@tcb.net'" <danny@tcb.net>,
 "'morrowc.lists@gmail.com'" <morrowc.lists@gmail.com>
Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft
 Agenda: 04-30-2012 (April 30, 2012)))
Thread-Index: AQHNKkSJz7TI33mXqEag9uIgDcAF15a6YCwk
Date: Sat, 5 May 2012 00:59:41 +0000
Message-ID: <CE0C4A314044C843AEE900875D90D54E108460@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F707BE6@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "'sidr-ads@tools.ietf.org'" <sidr-ads@tools.ietf.org>,
 "'sidr-chairs@tools.ietf.org'" <sidr-chairs@tools.ietf.org>,
 "'sidr@ietf.org'" <sidr@ietf.org>
Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft
 Agenda: 04-30-2012 (April 30, 2012)))
Precedence: list

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 n=
eed to do so with private keys that have been vouched for. But getting thes=
e private keys "onboard" routers that lie across (for example) foreign bord=
ers can be an operational nonstarter. For ex, if my router's key needs to b=
e voched for but its private portion (that signs updates) is sent over a me=
dium in which it can be intercepted, then how can I trust the signatures fr=
om 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' u=
pdates? =20

His point is NOT addressed by any draft in the wg (since you asked).

Hth,

Eric


----- Original Message -----
From: Murphy, Sandra [mailto:Sandra.Murphy@sparta.com]
Sent: Friday, May 04, 2012 06:24 PM=0A=
To: Danny McPherson <danny@tcb.net>; Christopher Morrow <morrowc.lists@gmai=
l.com>
Cc: sidr wg <sidr@ietf.org>; sidr-chairs@tools.ietf.org <sidr-chairs@tools.=
ietf.org>; sidr-ads@tools.ietf.org <sidr-ads@tools.ietf.org>
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 certif=
icates" means getting the private keys routers would use for signing into t=
he routers.

Because the below implies that the "signing certificates", i.e., private ke=
ys, would be "from the RPKI", I figure I'd better speak up.  Just in case s=
omeone 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 suppose=
d 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 conc=
ern.  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: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa=
ndra [Sandra.Murphy@sparta.com]
Sent: Wednesday, April 11, 2012 1:28 PM
To: Danny McPherson; Christopher Morrow
Cc: sidr-ads@tools.ietf.org; sidr-chairs@tools.ietf.org; sidr wg
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201=
2)

speaking as regular ol' member

On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [danny@tcb.net] 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 doe=
sn't
>currently support it, nor are the security implications clear].

I can not  understand your comment.  What do you mean by "signing certifica=
tes"?

I can guess that "validating certificates" means the certs carrying public =
keys used to validate signatures, but the "signing certificates" part has m=
e stumped.

--Sandy


________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh=
erson [danny@tcb.net]
Sent: Tuesday, April 10, 2012 9:15 PM
To: Christopher Morrow
Cc: sidr wg; sidr-chairs@tools.ietf.org; sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201=
2)

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 alr=
eady?  Or simply discussing solutions that have already been developed and =
deployment experience?  If the latter, then we can we ensure we reference a=
nd prepare to discuss what requirements drive to the development of those s=
olutions?
>>
>
> 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 pu=
rge signing and validating certificates to routers from the RPKI -- [I susp=
ect the intention was to use rpki-rtr protocol for this, but it doesn't cur=
rently support it, nor are the security implications clear].

Only when we get to that point will we really begin to understand the dynam=
ics of RPKI and it's employment for secure routing (well beyond "authorized=
" origin policy configuration), and the impact of rate+state in both the RP=
KI and it's effectuating in the routing system, and perhaps most importantl=
y, the inter-dependencies between the two (even basic stuff like the rate o=
f updates from an RPKI cache to a router in a fully loaded system given tod=
ay'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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr