Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt

[Tim Bruijnzeels <[e-mail]>]

Hi,

I believe that we should discuss the concerns raised by Rob. Whether that is in the context of a working group last call or not.. I don't really mind the process.

What is indeed important is that we ask ourselves what issue this draft solves, and what complexity, and which risks are introduced. We should ask the same questions about alternative paths and/or doing nothing.

The issue that motivated me to invest time in this, is that without automation you will lose RPs when there is a change in the TAL. People will just not update until they find that suddenly a TA they had configured disappears - and they may not notice this for a while. In the context of ROV the landing is relatively soft: things become 'not found', but it is a landing nonetheless.

I saw Ben Cox present a data plane analysis at the nlnog day 2018, and again 2019. He found that there is a significant number of people who do not enable the ARIN Tal, presumable simply because it could not be included. See slide 44 (!) of this presentation:
https://nlnog.net/static/nlnogday2018/8_Measuring_RPKI_ben_NLNOG_2018.pdf

Regarding the RPA, I am afraid that it too will be problematic w.r.t. renewals. Nowadays one can ship the actual file, but users still need to take action to accept. It is not clear to me whether this implies that they can accept an updated TAL without interacting (beyond updating the software).

In any event the difference in drops between RIPE invalids and ARIN invalids in that presentation exemplify how many users would be unaware of an issue. And could be late updating.

We could, of course, accept all of the above. We could decide that the complexity and other risks introduced by this draft are simply not worth it. Do not get me wrong, I co-authored, but I have no fatherly feelings that stop me from having the discussion.

I expressed earlier that I believe that this document can be simplified if we limit the amount of simultaneous keys to two. It could be simplified even further if we only allowed forward rolls. Whether that is the right choice depends on what we are trying to solve.

With regards to risks introduced. It is undeniably true that simply by having two keys, only one of them needs to be subverted to end up in a bad place. The attack surface is increased. However, most TA operators use HSMs and M/N processes in signing, which in my mind provide enough protection against key theft, and key abuse. So it was a deliberate choice that this draft does not even try to solve those issues, and accepts that it is itself vulnerable to such issues. 

The main motivation here is forward rolls from one HSM vendor to another. The secondary motivation is to protect against key loss (card set lost, broken HSM, people no longer with us). The latter is why the complexity regarding aborting a roll to key 'b' and introducing a new key 'c' was introduced. What if you plan to go to 'b' but you lost access to it.

On the whole I am still in favour of the automation, but I welcome a healthy discussion where pros and cons are weighed :)

Tim





> On 27 Feb 2020, at 23:30, George Michaelson <[e-mail]> wrote:
> 
> I'd like it if we could go WGLC. I think it takes a stronger signal of
> commit and contentment in the WG. Our author discussion on "where
> next" is a bit cold right now, because there isn't much to do, but we
> don't have words for what there is to do.
> 
> How about we put that to the ML or F2F? Which I guess, is what you just did.
> 
> I stole the edit token. I'd be happy to let my esteemed co-authors and
> the WG tell me what they want here. Probably, confusion in my part put
> it to WGLC but if it is there, why don't we treat it seriously and ask
> if its ready?
> 
> We need a mechanism to signal intent to change TAL. Automation is a
> "step too far" for some people, Rob Kisteleki has spoken to the
> inherent risks, and the concern it does not "fix" risks some people
> think it may, because an ability to subvert the TAL implies an ability
> to subvert the signature over the TAL, and so force communities to
> inherit a new TAL, of bad intent. The DNS root process with in-band
> signal is a different world. We can learn from it, but it may not show
> what general X509 PKI models think is a good way to do this.
> 
> Rob suggested we consider why browsers ship TA changes by updating
> code. That moves the burden to a body who agrees what TAL need to be
> shipped, and liaison with the Validator authors and release processes.
> 
> Or, a hand-run process to use this mechanism.
> 
> Or, a signalling mechanism to flag "this TAL needs to change" but the
> actual decision to change, is hand-managed buy the RP.
> 
> Basically, I don't know why it flagged WGLC but I think it is not far
> off, and I would like it to close.
> 
> -G
> 
> On Fri, Feb 28, 2020 at 4:33 AM Christopher Morrow
> <[e-mail]> wrote:
>> 
>> Howdy WG Peepls!
>> This document got marked somewhere in the datatracker as: "WGLC"...
>> which seems awesome, but I didn't see/remember actually doing that :(
>> 
>> Do the authors feel this document is ready for WGLC? If so we can get
>> that started :) If not I'll go re-set the status in datatracker.
>> 
>> On Wed, Jan 15, 2020 at 10:29 PM <[e-mail]> wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the SIDR Operations WG of the IETF.
>>> 
>>>        Title           : RPKI Signed Object for Trust Anchor Keys
>>>        Authors         : Carlos Martinez
>>>                          George G. Michaelson
>>>                          Tom Harrison
>>>                          Tim Bruijnzeels
>>>                          Rob Austein
>>>        Filename        : draft-ietf-sidrops-signed-tal-05.txt
>>>        Pages           : 16
>>>        Date            : 2020-01-15
>>> 
>>> Abstract:
>>>   A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by
>>>   Relying Parties (RP) in the RPKI to locate and validate a Trust
>>>   Anchor (TA) CA certificate used in RPKI validation.  This document
>>>   defines an RPKI signed object for a set of Trust Anchor Keys (TAK),
>>>   that can be used by TA creators and publishers to signal their set of
>>>   current keys and the location(s) of the accompanying CA certificates
>>>   to RPs, as well as changes to this set in the form of revoked keys
>>>   and new keys, in order to support both planned and unplanned key
>>>   rolls without impacting RPKI validation.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-05
>>> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-05
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-05
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> Sidrops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops