Subject: [karp] rt-dir review of draft-ietf-karp-crypto-table

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 08:29:45 -0400

I've already written back indicating that i don't think we want to
change the scope of this document or of the KARP working group.
As such, I don't think we want to address issues 1 and 6

Similar i'm sure we're correct with regard to issue 7.

I'll propose comments on some of the other issues in follow-ups to this
message.

Subject: FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Danny McPherson'" <[email-masked]>
Date: Sun, 12 May 2013 21:13:54 +0100
List-Id: <[email-masked]>

All,

I am attaching Danny's routing directorate review of your draft. Please read his note below.

As IETF last call has completed, you do not need to heed these comments in the same way as you might for comments coming during IETF last call.

However, the ADs will be sifting through what Danny has written and potentially adding issues he raises to our Discusses/Comments. In view of that, you may feel it wise to read what he has written and see whether you are moved to answer his questions and maybe update the text.

Thanks,
Adrian

> -----Original Message-----
> From: Danny McPherson [mailto:[email-masked]]
> Sent: 12 May 2013 20:57
> To: BRUNGARD, DEBORAH A
> Cc: [email-masked]; [email-masked]; Dan Li
> ([email-masked])
> Subject: Re: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table
> 
> Review attached, apologies for the latency.  Also, I'm sending this
> without a full review of the review so if anything seems abrasive it
> wasn't meant to be..
> 
> Thanks,
> 
> -danny

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 May 2013 11:59:06 -0400

I agree with Sam that the scope for this doc makes the first comment out 
of scope.

More importantly, the RPKI and BGPSEC are not relevant to the key table 
design. The former requires
no crypto operations on a router. The latter deals with keys for 
routers, but management of these keys
is very different, precisely because they are public keys.

Steve
-------
On 5/21/13 8:29 AM, Sam Hartman wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 May 2013 15:56:22 +0900

> More importantly, the RPKI and BGPSEC are not relevant to the key
> table design. The former requires no crypto operations on a
> router. The latter deals with keys for routers, but management of
> these keys is very different, precisely because they are public keys.

that last clause is false.  in bgpsec, the router has at least one
private key so that it can sign announcements.

i am scratching my head on whether a karp table entry could be helpful
in the use of bgpsec keys, and have not found a clear need.  but this
could be my fault.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 May 2013 11:39:26 -0400

Randy,

You're right that each BGPSEC router has a private key. However, the key 
table is
designed to manage key rollover for keys that are shared on a pairwise 
basis.
The private router key does not have that property, so it seems a bad fit.
I should have been more precise in my reply.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 May 2013 15:08:39 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> Randy, You're right that each BGPSEC router has a private
    Stephen> key. However, the key table is designed to manage key
    Stephen> rollover for keys that are shared on a pairwise basis.  The
    Stephen> private router key does not have that property, so it seems
    Stephen> a bad fit.  I should have been more precise in my reply.

Here are some of the reasons I think the key table is a bad fit for
managing asymmetric key pairs:

* Symmetric key pairs have both a public and private portion.  The
  current key table is designed assuming a single asymmetric key.  It
  doesn't have a concept of a portion of a key row that can be public
  nor does it have a concept of making sure the public key corresponding
  to a private key row is available.

* You often need additional public information such as certificates (or
  in some cases CRLs or cached OCSP responses) to provide to a relying
  party to make an asymmetric key useful.  The key table is not designed
  to manage this information.  I don't know much about BGPSEC, but my
  assumption is that it builds on the RPKI's certificate and key
  management practices.  If so, those practices seem very specialized to
  build into something like the key table.

* The concepts of peers, interfaces, key names and protocol specific
  information seem inappropriate to private keys.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 May 2013 12:34:49 -0400

On 5/23/13 3:08 PM, Sam Hartman wrote:
> * Symmetric key pairs have both a public and private portion.
asymmetric
>    The
>    current key table is designed assuming a single asymmetric key.
symmetric
>    It
I agree that the key table is not a good fit for these reasons.
>    build into something like the key table.
more good reasons. Yes, BGPSEC makes use of the RPKI for distribution
of certs and CRLs for router keys.
>    information seem inappropriate to private keys.
secret

Yes, BGPSEC router keys are neither peer nor interface-specific.

Steve