Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 7 Mar 2012 22:40:25 +0000

The following request has been made for wg adoption of draft-ymbk-bgpsec-rtr-rekeying-00.txt.

The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01.

Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group.

This call will end 21 Mar 2012.

--Sandy, speaking as wg co-chair

________________________________________
From: [email-masked] [[email-masked]] on behalf of Randy Bush [[email-masked]]
Sent: Monday, March 05, 2012 8:54 PM
To: sidr wg list
Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt

chairs, please consider as a wg work item.  thanks.

randy

---

From: [email-masked]
Subject: New Version Notification for draft-ymbk-bgpsec-rtr-rekeying-00.txt

A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been succes=
sfully submitted by Sean Turner and posted to the IETF repository.

Filename:        draft-ymbk-bgpsec-rtr-rekeying
Revision:        00
Title:           Router Keying for BGPsec
Creation date:   2012-03-05
WG ID:           Individual Submission
Number of pages: 7

Abstract:
   BGPsec-speaking routers must be provisioned with private keys and the
   corresponding public key must be published in the global Resource
   PKI.  This document describes two ways of doing so, router-driven and
   operator-driven.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 7 Mar 2012 23:07:51 +0000

An alert eye pointed out that the URL below is incorrect.  The correct pointer is

http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00

--Sandy, speaking as clumsy wg co-chair

________________________________________
From: [email-masked] [[email-masked]] on behalf of Murphy, Sandra [[email-masked]]
Sent: Wednesday, March 07, 2012 5:40 PM
To: [email-masked]
Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt

randy

---

Abstract:

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Mar 2012 16:13:35 -0400

Well I'd like to see it adopted and I promise to work on it ;)

spt

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 24 Mar 2012 06:18:55 -0400

<crickets>
Hey folk,
Is this draft stating something obvious and doesn't need to be
documented? or are we in need of this doc to keep us all on the same
page (us == ops + vendors) as to getting a cert created and installed
on our lovely devices?

If people could take a few minutes to read the 4 pages (minus
boilerplate) and think/comment that would be nice.

(for the record, it seems like documenting this is a good thing, from
my perspective.)

-chris

On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner <[email-masked]> wrote:
>> The draft is available at
>> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01.
>>
>> Please respond to the list to say whether you accept this draft as a
>> working group draft and are willing to work on it. Remember that you do not
>> need to accept all content in a draft to adopt, as draft editors are
>> required to reflect the consensus of the working group.
>>

---

From: Rob Austein <[email-masked]>
Date: Sat, 24 Mar 2012 13:33:52 +0100

Have read and support adoption.

---

From: Matt Lepinski <[email-masked]>
Date: Sat, 24 Mar 2012 08:52:26 -0400

I have read now this document.
The issues discussed in this document are issues should be documented 
somewhere.
(It is possible that this could be rolled into another document, since 
its short, but this stuff definitely should be documented in some 
product of the SIDR working group)
I really appreciate that the authors took the time to document these issues.

On 3/24/2012 6:18 AM, Christopher Morrow wrote:
> On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner<[email-masked]>  wrote:

---

From: "George, Wes" <[email-masked]>
Date: Sat, 24 Mar 2012 09:33:38 -0400

Yes, support. Anything that teaches router jockeys how to wrangle keys and not compromise the security of the system in the process is a good thing IMO.

Though I'm wondering if perhaps this doc and bgpsec-rollover should be integrated

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Saturday, March 24, 2012 6:19 AM
> To: Sean Turner
> Cc: Murphy, Sandra; [email-masked]
> Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt
>
> <crickets>
> Hey folk,

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 24 Mar 2012 09:42:16 -0400

> Though I'm wondering if perhaps this doc and bgpsec-rollover should be integrated

interesting... so you mean:
<http://tools.ietf.org/html/rfc6489.txt>

or something else? I think a doc just talking about 'network equipment
handling of certs' is good, mingling in with 'if I want to roll the
key on my CA, I do ...' seems like hiding the sausage in the wrong
place. (or maybe not the wrong place, but not the right one
either....) Sure, the 2 items are potentially linked, but... the CA
bits cover a lot more ground, so I would say more chance for confusion
and mistakes due to complexity.

-chris

---

From: Matt Lepinski <[email-masked]>
Date: Sat, 24 Mar 2012 10:02:11 -0400

Chris,

No, I believe Wes is talking about: 
http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00

- Matt Lepinski

On 3/24/2012 9:42 AM, Christopher Morrow wrote:
> On Sat, Mar 24, 2012 at 9:33 AM, George, Wes<[email-masked]>  wrote:

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 24 Mar 2012 10:05:38 -0400

> http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00

oh :) burried further down the list :( Sorry, that seems to make a
clearer link to why combination would be good.

thanks!
-chris

>>> Yes, support. Anything that teaches router jockeys how to wrangle keys
>>> and not compromise the security of the system in the process is a good thing
>>> IMO.
>>>
>>>>>> From: [email-masked] [[email-masked]] on behalf of
>>>>>> Murphy,
>>>>>> Sandra [[email-masked]]
>>> This E-mail and any of its attachments may contain Time Warner Cable
>>> proprietary information, which is privileged, confidential, or subject to
>>> copyright belonging to Time Warner Cable. This E-mail is intended solely for
>>> the use of the individual or entity to which it is addressed. If you are not
>>> the intended recipient of this E-mail, you are hereby notified that any
>>> dissemination, distribution, copying, or action taken in relation to the
>>> contents of and attachments to this E-mail is strictly prohibited and may be
>>> unlawful. If you have received this E-mail in error, please notify the
>>> sender immediately and permanently delete the original and any copy of this
>>> E-mail and any printout.
>>

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 24 Mar 2012 10:09:25 -0400

> clearer link to why combination would be good.

oh, except that the -rollover doc says:
"The BGPSEC key roll-over process should be very tighten to the key
   provisioning mechanisms that would be in place.  The key provisioning
   mechanisms for BGPSEC are not yet documented.  We will assume that
   such an automatic provisioning mechanism will be in place (a possible
   provisioning mechanism when the private key lives only inside the BGP
   speaker is the Enrollment over Secure Transport (EST).  This protocol
   will allow BGPSEC code to include automatic re-keying scripts with
   minimum development cost."

in the second sentence it's asking for this doc... (the first sentence
seems to have some missing words though)

---

From: Warren Kumari <[email-masked]>
Date: Sat, 24 Mar 2012 16:19:08 +0100

Read and support…

Sorry, there are so many drafts, I can never keep clear which ones I have already supported…

W

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: "George, Wes" <[email-masked]>
Date: Sat, 24 Mar 2012 16:37:20 -0400

> Sent: Saturday, March 24, 2012 10:09 AM
> To: Matt Lepinski
> Cc: [email-masked]

[WEG] the cited text can be changed, especially now that the referenced documentation exists. :-)
My point was not that all of the information isn't important, but rather that this occupies similar space and I don't know that it needs to be separated, other than as a separate section in one document. This WG generates a lot of documents that are logically separated by subject matter, but by necessity very intertwined, which sometimes makes it hard for those not intimately involved in writing/reviewing the drafts to keep track of what information is discussed where, and requires a fair amount of cross-referencing to truly understand the implementation. I'm thinking that if there are obvious places to consolidate, we should do so.

Wes

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Mar 2012 03:58:25 -0400

>(for the record, it seems like documenting this is a good thing, from

I think these issues need to be documented somewhere. It's helpful
to note motivations for central key generation (e.g., quick restoral
of service when a router fails and hardware is replaced), which
might otherwise be lost. Finally, we're working on a new cert provisioning
protocol in PKIX and this provides a basis for making sure this capability
is part of that protocol.

That said, it might make sense to combine this doc and the key rollover
doc that is another individual submission, of we want to reduce the
number of distinct SIDR docs.

Steve

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 28 Mar 2012 05:05:43 -0400 (EDT)

Have read and support adoption.  I like the general idea.  I don't 
have comments on the particular wrappings chosen.

Minor comments:

It might be better to not specify the cryptosuite(s) in use -- aren't 
those documented in draft-ietf-sidr-bgpsec-algs?  (ECDSA is named in 
sections 1 and 4.)

The current security considerations section seems applicable only to 
the operator-generated model.  You might want to say something about 
the other model.  And for the operator-generated model, you may want 
to add a (flip) comment about transport security being "keep your hand 
on the USB key".  This almost looks like a use for Resurrecting 
Duckling keying methods.

-- Sam