Subject: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-signed-tal-01

From: Keyur Patel <[email-masked]>
Date: Tue, 10 Oct 2017 17:19:34 +0000

Hi Folks,

The authors have requested SIDROPS working group adoption call of draft-tbruijnzeels-sidrops-signed-tal-01, “RPKI signed object for TAL”. Please send your comments to the list.

This adoption call will conclude on Oct 25 2017.

Regards,
Chris & Keyur

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 11 Oct 2017 14:52:45 +0200

Dear WG,

As co-author I will leave it to others to support or indeed oppose this.

But, I would like to remind you all of the message I sent on this just after IETF99:

> Dear working group,
> 
> Following the discussion at the microphone at IETF99, we have uploaded an updated version of the signed TAL document:
> https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidrops-signed-tal/
> 
> Two issues were brought up:
> 
> 1) magic numbers used for staging periods
> 
> We removed the time after which a Signed TAL should be removed - opting instead for a model where a TA can publish what it believes should be considered its current TAL at all times. RPs that have already learned this TAL can just ignore it. 
> 
> We kept 24 hour staging period in key rolls (section 6.2). I don’t think we strictly need it to be honest, but it is in-line with how things are done in CA key rolls (RFC6489).
> 
> We also kept a 24 hour period when withdrawing a publication point. Although there is no explicit guarantee about how frequently RPs re-sync, most RPs do use a much high frequency than this. The 24 hour value is in-line with key rolls, and should be more than enough time.
> 
> 2) Lessons from RFC5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors)
> 
> As I read the mechanisms described here are not applicable to RPKI because we do not have explicit TTLs defined, and we do not have the concept of Trust Anchor Sets. Therefore we still propose a model based on the existing TAL format that we believe is simpler.
> 
> 
> We would now like to ask for working group adoption of this document.
> 

And to repeat the goal of this effort: we want a way to do a planned roll of our TA key (currently we are locked into our HSM vendor), and we want to be able to do planned changes in where we publish our TA certificate. In a way that deployed RP software can learn about these changes automatically.

We did not intend this document to be useful for emergency key rolls, where the old key is lost or stolen. I am not opposed to solving that issue, but it’s not a problem we expect to have. Furthermore I expect it would require a much more complicated setup - possibly involving a set of TAs where (a quorum of?) remaining TAs can add/remove new TAs - at least that’s more or less what I get from RFC5011. This is much more involved issue, so I would prefer to discuss it separately and not have it stand in the way of solving the above issues that we do have.

Kind regards

Tim

> On 10 Oct 2017, at 19:19, Keyur Patel <[email-masked]> wrote:
> 
> Hi Folks,
>  
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2017 16:53:19 -0400

I think planned TA keyrolls are an appropriate work item for this
group, therefore I support adoption.

-andy

On Tue, Oct 10, 2017 at 1:19 PM, Keyur Patel <[email-masked]> wrote:
> Hi Folks,
>
>
>
> The authors have requested SIDROPS working group adoption call of
> draft-tbruijnzeels-sidrops-signed-tal-01, “RPKI signed object for TAL”.
> Please send your comments to the list.
>
>
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 12 Oct 2017 15:36:17 -0700

support. We should discuss this.

-G

PS https://tools.ietf.org/html/rfc5934

---

From: "Andy Newton" <[email-masked]>
Date: Thu, 12 Oct 2017 20:42:02 +0000

I think planned TA keyrolls are an appropriate work item for this group, 
and therefore support adoption.

-andy

------ Original Message ------
From: "Keyur Patel" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 10/10/2017 1:19:34 PM
Subject: [Sidrops] WG Adoption call for 
draft-tbruijnzeels-sidrops-signed-tal-01

---

From: Daniel Shaw <[email-masked]>
Date: Fri, 13 Oct 2017 11:52:51 +0400

>> Please send your comments to the list.

I support the WG taking on this work.

- Daniel

---

From: Di Ma <[email-masked]>
Date: Fri, 13 Oct 2017 16:38:27 +0800

I support adoption of this document and will take part in discussions on it.

Di

> 在 2017年10月11日，01:19，Keyur Patel <[email-masked]> 写道：
> 
> Hi Folks,
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Oct 2017 11:35:38 -0700

> group, therefore I support adoption.

i like this phrasing

randy

---

From: Amreesh Phokeer <[email-masked]>
Date: Fri, 13 Oct 2017 22:11:48 +0200

> Please send your comments to the list.

Agree that this will be very useful and I support adoption.

---

From: "Yu Fu" <[email-masked]>
Date: Tue, 17 Oct 2017 14:31:22 +0800

Hi all,

I support the WG adoption as I think it is a meaningful work.

Cheers

Yu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keyur Patel
Sent: Wednesday, October 11, 2017 1:20 AM
To: [email-masked]
Subject: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-signed-tal-01

Hi Folks,

Regards,

Chris & Keyur

---

From: ALAIN AINA <[email-masked]>
Date: Tue, 17 Oct 2017 11:11:34 +0000

> On 13 Oct 2017, at 20:11, Amreesh Phokeer <[email-masked]> wrote:
> 

I also support adoption. Looking forward to the discussion.

—Alain

---

From: Rob Austein <[email-masked]>
Date: Thu, 19 Oct 2017 15:21:19 -0400

We can discuss whether the mechanism as described is precisely right,
what we can steal\\\\\learn from RFC 5011, et cetera, but I'm pretty
sure we need something in this space.

Support adoption.