Subject: [sidr] Signaling / notifying RPs of an upcoming TAL change

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 2 Aug 2013 12:26:09 +0200

Hello all,

Several of us, in some cases independently, have been discussing the
possible need of signaling RPs about an upcoming TAL change.

We don't have a common proposal and there is no I-D (yet!), but we would
like to hear the list's feedback / thoughts on the issue.

Cheers!

Carlos

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Aug 2013 13:05:53 +0200

notify which rps?

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 2 Aug 2013 21:13:29 +1000

> notify which rps?

esp

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Aug 2013 13:15:06 +0200

> esp

better than ah

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 2 Aug 2013 13:30:55 +0200

> notify which rps?

All RPs that trust the current TAL

The TA may need this because:
= They need to do a planned roll of the key
     - e.g. we use an HSM of vendor X, we may want to change vendor, vendor can go out of business etc

= They need to change the one current publication point
= They need to add/remove publication points - if multiple becomes standard

I agree that it's much better to prevent all these needs, but I don't think it's possible to commit to that when long key life (decades) is the objective.

Tim

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Aug 2013 13:33:23 +0200

> All RPs that trust the current TAL

oh, the ones who signed arin's lawyer silliness?  :)

the point geoff and i are jokingly making is that you do not really know
all the parties relying on a ca

randy

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 2 Aug 2013 15:25:31 +0200

Sorry for the loose use of the word 'notify'. In Spanish una 'notificación'
can go both ways. It's true that in English and in the IETF a 'notify'
message implies knowledge of clients on part of servers.

Moving on, what we all had in mind was some sort of signaling that would
warn a RP of an upcoming TAL change. Some form of shelf life, or
'better-check-for-new-one' time indication would IMO suffice, but I believe
that this thing deserves some thought.

regards

Carlos

On Fri, Aug 2, 2013 at 1:33 PM, Randy Bush <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Andrew Chi <[email-masked]>
Date: Fri, 02 Aug 2013 18:42:25 +0200

I'm not yet proposing the following mechanism, as I've only thought 
about it for 15 minutes.  But just as clarification, I think Carlos is 
asking for something like RFC5011 (Automated Updates of DNSSEC Trust 
Anchors).  Terry Manderson, you came up and pointed us to 5011, so would 
you mind elaborating in case I get it wrong?

Dave Mandelberg mentioned the following to me: In the normal case 
(non-emergency, planned way ahead of time), use the existing trust 
anchor to announce a future TAL.  An RIR issues (under its existing TA) 
a special signed object containing the future TAL and the intended 
activation date.  The RP software MUST NOT automatically update the TAL 
without operator verification.  The RP software SHOULD display a message 
such as:

   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   @    WARNING: TRUST ANCHOR LOCATOR SCHEDULED TO CHANGE!   @
   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   IT IS POSSIBLE THAT SOMEONE IS PLANNING SOMETHING NASTY!
   It is also possible that this is normal TA key rollover.
   The new TAL information is:
   << FOO >>
   Please ask your system administrator to verify the new TAL.
   To accept the TAL and get rid of this message, modify <<CONFIGFILE>>.
   << additional instructions >>

I just stole the "SSH host key changed" warning, but you get the idea.

Carlos, is this the sort of thing you're asking for?

Andrew

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Aug 2013 04:43:39 +1000

On 02/08/2013, at 11:25 PM, Carlos Martinez-Cagnazzo <[email-masked]> wrote:

> Sorry for the loose use of the word 'notify'. In Spanish una 'notificación' can go both ways. It's true that in English and in the IETF a 'notify' message implies knowledge of clients on part of servers.
> 
> Moving on, what we all had in mind was some sort of signaling that would warn a RP of an upcoming TAL change. Some form of shelf life, or 'better-check-for-new-one' time indication would IMO suffice, but I believe that this thing deserves some thought.

a check to see if one needs to check?

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sat, 3 Aug 2013 12:06:41 +0200

Hi Andrew,

On Aug 2, 2013, at 6:42 PM, Andrew Chi <[email-masked]> wrote:

> I'm not yet proposing the following mechanism, as I've only thought about it for 15 minutes.  But just as clarification, I think Carlos is asking for something like RFC5011 (Automated Updates of DNSSEC Trust Anchors).  Terry Manderson, you came up and pointed us to 5011, so would you mind elaborating in case I get it wrong?
> 
> Dave Mandelberg mentioned the following to me: In the normal case (non-emergency, planned way ahead of time), use the existing trust anchor to announce a future TAL.  An RIR issues (under its existing TA) a special signed object containing the future TAL and the intended activation date.

This is similar to what I suggested in my reply to comment on multiple publication points.

So to re-phrase Carlos' intention regarding signalling. RPs validate regularly so they can find this object. Polling is fine. Time scales for planned rolls should be long.

> The RP software MUST NOT automatically update the TAL without operator verification.  The RP software SHOULD display a message such as:
> 

> I just stole the "SSH host key changed" warning, but you get the idea.

I think this warning is too strong.

It's signed by the TA certificate. Or well I expect the TAL to be published in normal RPKI signed object: a CMS with an EE cert signed by the TA.

If you trust the TA to sign other things in the RPKI, then why not trust it to say: "I am about to retire, but look I have a successor."

The extend of automating updating the TAL by RP software is local policy in my view. I agree that keeping the user in the know of this is good karma. On the other hand, if we are to have a formal way of rolling a TAL then I think a "RP SHOULD start to use the new TAL at point in time X, and SHOULD stop using old TAL at time Y (later)" are in order.

I understand that this adds to complexity to an already complicated system. That said I think we need to be able to do planned key rolls (e.g. HSM lifetime) and change publication points of TA certificates.

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Aug 2013 20:21:28 +1000

> If you trust the TA to sign other things in the RPKI, then why not trust it to say: "I am about to retire, but look I have a successor."

I am trying to understand the situation with a compromised key where the evil party says "I am about to retire, but look I have a sucessor." Could you help me understand how this could not happen in the procedure you've proposed?

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sat, 3 Aug 2013 14:36:14 +0200

> I am trying to understand the situation with a compromised key where the evil party says "I am about to retire, but look I have a sucessor." Could you help me understand how this could not happen i…

This is a (incomplete) proposal for a planned roll of a un-compromised key.

Ah.. hold on.. okay. So essentially your saying this, right?
	"Imagine that an evil party steals the key, and then points RPs to a new TA under it's own control? The RPs have no way of knowing the old key was compromised."

I have to admit that I did not think of that.

That said, the situation where a root key actually gets stolen is pretty bad without this. It would still require public statements in all imaginable media to get RPs to stop trusting the compromised key. So, I am not convinced that this is actually a lot worse.

On the other hand I do see a use case for planned rolls. Changing publication points to TA certs (or adding/removing), and doing a planned roll (e.g. when changing HSM vendors - most HSMs will allow safe transfer of keys to newer models by the same vendor, but between vendors.. not so likely).

Tim

---

From: Geoff Huston <[email-masked]>
Date: Sun, 4 Aug 2013 06:26:46 +1000

> On the other hand I do see a use case for planned rolls. Changing publication points to TA certs (or adding/removing), and doing a planned roll (e.g. when changing HSM vendors - most HSMs will allo…

I am struggling to understgnd the motivation for the use case noted above for "planned rolls". If the procedures cannot handle key compromise then what is the motivation for rolling the key?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 05 Aug 2013 13:36:30 -0400

Tim,

>> ...
The current TAL is not an RPKI signed object. But, one might define an 
object that is
stored in the RPKI as a way for an TA to announce a planned change to 
the TAL, and to
deliver a new TAL.
> If you trust the TA to sign other things in the RPKI, then why not trust it to say: "I am about to retire, but look I have a successor."
agreed.
> The extend of automating updating the TAL by RP software is local policy in my view. I agree that keeping the user in the know of this is good karma. On the other hand, if we are to have a formal w…
agreed, but I still think human intervention (notification and ack) is a 
good idea.
> I understand that this adds to complexity to an already complicated system. That said I think we need to be able to do planned key rolls (e.g. HSM lifetime) and change publication points of TA cert…
yes.

Steve

---

From: Andrew Chi <[email-masked]>
Date: Mon, 05 Aug 2013 17:36:59 -0400

On 8/5/2013 1:36 PM, Stephen Kent wrote:
>> The extend of automating updating the TAL by RP software is local
>> policy in my view. I agree that keeping the user in the know of this
>> is good karma. On the other hand, if we are to have a formal way of
>> rolling a TAL then I think a "RP SHOULD start to use the new TAL at
>> point in time X, and SHOULD stop using old TAL at time Y (later)" are
>> in order.

As Geoff indicated, automatically updating a TAL is problematic if the 
key really has been compromised.  DNSSEC uses a hold-down timer to 
mitigate but not completely solve this problem (RFC 5011, Section 2.2).

Without additional safety measures, relying parties REALLY SHOULD NOT 
(*) update their TALs automatically.

Andrew

*) The phrase "REALLY SHOULD NOT" is used to indicate dangerous
    behaviors that some important vendor still does and therefore we were
    unable to make MUST NOT.  (RFC 6919, section 3)

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 6 Aug 2013 18:13:18 +0200

On Aug 5, 2013, at 7:36 PM, Stephen Kent <[email-masked]> wrote:

> The current TAL is not an RPKI signed object. But, one might define an object that is
> stored in the RPKI as a way for an TA to announce a planned change to the TAL, and to
> deliver a new TAL.

Ack, that is what I meant.

> agreed, but I still think human intervention (notification and ack) is a good idea.

Agreed, also pointed out by Andrew in his reply.

Geoff, would such an explicit requirement for human intervention address your concerns regarding key compromises?

>> I understand that this adds to complexity to an already complicated system. That said I think we need to be able to do planned key rolls (e.g. HSM lifetime) and change publication points of TA cer…

Yes to both use cases?

Of course.. I realise I went off into a high level implementation idea. But the more important question right now is whether the WG agrees that this is a problem (use case) we should fix. I think it is, and you seem to agree. What about others?

I understand there are many more details to consider before we have a solution. RFC5011 (updating dnssec TAs) referred to by Andrew, can be of use here.

Tim

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 06 Aug 2013 13:41:38 -0300

Hello,

On 8/6/13 1:13 PM, Tim Bruijnzeels wrote:
> ... snip ...
I definitely agree there is a use case / problem that needs to be
addressed. As to which a proper solution would look like, I don't have
an opinion yet, but that should, imo, go into a separate thread.
> I understand there are many more details to consider before we have a solution. RFC5011 (updating dnssec TAs) referred to by Andrew, can be of use here.
There is also Terry's reference to RFC 5914, Trust Anchor Format. I, for
one, prefer the much easier to manage/edit and parse plain-text TAs we
have now, but as we add more fields to TAs, we might want to look at
5914 to either avoid reinventing the wheel, or to decide that we have
good reasons for reinventing it.

If we need a more expressive plain text format, there is always JSON
(joke, don't start flaming) :-)

> Tim
cheers!

Carlos

---

From: Stephen Kent <[email-masked]>
Date: Tue, 06 Aug 2013 16:57:53 -0400

Tim,

>>> I understand that this adds to complexity to an already complicated system. That said I think we need to be able to do planned key rolls (e.g. HSM lifetime) and change publication points of TA ce…
Yes for key roll, because very unlikely events that might make a private 
key unavailable
will, eventually, happen.

I think the pub point woild need to change because we may need to 
publish the new
TA cert in parallel with the old one, for a =n orderly transition. if 
not, then I'd
stick with just a key change.

Steve

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 06 Aug 2013 17:59:45 -0300

If we consider de "multiple publication points" scenario, then an
addition/change/removal of a publication point would also trigger a TAL
change.

Cheers!

Carlos

On 8/6/13 5:57 PM, Stephen Kent wrote:
> Tim,
>
>> ...
>>>> I understand that this adds to complexity to an already complicated
>>>> system. That said I think we need to be able to do planned key
>>>> rolls (e.g. HSM lifetime) and change publication points of TA
>>>> certificates.
>>> yes.
>> Yes to both use cases?
> Yes for key roll, because very unlikely events that might make a
> private key unavailable

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 06 Aug 2013 18:00:45 -0300

Hello,

cheers!

Carlos

---

From: Stephen Kent <[email-masked]>
Date: Tue, 06 Aug 2013 17:26:23 -0400

Carlos,

That's an argument against multiple pub points for TAs :-) .
Steve

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 07 Aug 2013 17:55:54 -0300

Stephen,

Can you be more specific? It's hard to imagine a viable multiple pub
points scenario without a means for maintaining your pub point set, and
this would mean that TALs would/could change. Not very often though, but
more often than the 'will never change' hypothesis the current documents
seem to adscribe to.

regards

~Carlos

---

From: Stephen Kent <[email-masked]>
Date: Wed, 07 Aug 2013 17:07:21 -0400

Carlos,

Note the smiley face at the end of my comment.

If pub points change VERY infrequently, no problem.

Otherwise, this model is at odds with the TAL design.

Steve

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 07 Aug 2013 18:10:11 -0300

Hehe  :-)

I do believe that changes would be few and far between, let's say when
you establish an agreement with a repository operator, or you cancel
one. I don't really think these changes will be very frequent, in most
cases they'll last for years. However, I'm not sure it would be OK to
mandate that on an RFC (although some guidance could be included).

regards

Carlos