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

From: Christopher Morrow <[email-masked]>
Date: Mon, 27 Apr 2020 18:13:39 -0400

I think the gist of the discussion here is: "ERR WGLC was a nice
thought, it got us talking/thinking.... more thought/edits
forthcoming!"

is that about right?

On Fri, Mar 6, 2020 at 1:42 PM Randy Bush <[email-masked]> wrote:
>
> automatic modification of trusted credentials is scary.  but assuming
> the folk who understand the bgp and server configurations have not moved
> to marrakesh is naïve.
>
> as to pre-notification of an upcoming automatic change; i suspect very
> few who are not in this 'room' actually monitor rpki caches in any way.
> this will not improve.
>
> will such dilemmas drive us toward centralised cache services at google,
> yandex, ...?  and then we will have serious transport security issues.
>
> i wanna go back to 1996.

Just call up your friend Dr Brown and make it happen...
you may have to agree to drive your station-wagon at 88mph though.

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 27 Apr 2020 15:17:33 -0700

>> yandex, ...?  and then we will have serious transport security issues.

that was just one curmudgeon's opinion.  worth every penny you paid.

but i would not be unhappy to see this explained and discussed more

randy

---

From: George Michaelson <[email-masked]>
Date: Tue, 28 Apr 2020 08:25:36 +1000

There are (at least) three ways you can be taken to changing a TAL

1) because you receive "strongly" out-of-band signals such as a mail
list notification, or a website change you see (RSS?) or
word-of-mouth.

2) because the software updates, and you are given new TAL and a
README explains (this is how browsers update the trust anchor set at
present)

3) the missing third mechanism: an in-band signal informs you that a
TAL you trust is signing intent to move to a new TAL.

Robert K noted that if your primary concern is the distribution
problem this is fine, but if the risk is subversion of the TAL itself,
in-band signalling is actually weak, because the subverted signing
system can be used to signal a move to a new keypair in the bad
people's hands.  Robert preferred we focus on 2) but this places the
burden and responsibility into the same process issues we see with the
secret committee which white- and black- lists the TA set in the
browser. OTOH that is a process vested in "the community" in some
sense.

1) and 2) is how we do things at present. The draft tries to present
3). It riffs on the concepts in the DNSSEC key rolling. Signal intent,
allow both, signal deprecation on the old key.

Others (Randy?) have pointed out that if you want to do 3) like DNSSEC
you need to invoke "trust' in a higher, non-software bounded sense:
people need to see what you do. It opens the door to 'ceremonies'
because they are the vehicle which builds trust in that space. Its a
person cost, and a process cost.

I don't think the draft has much more which can be said. It could try
to capture the risk side, it could try to capture the ceremony side.
We implemented an early version and its simple to script, so I don't
see technology as the barrier here.

-G

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Apr 2020 00:01:56 -0400

> allow both, signal deprecation on the old key.

both 1 and 2 leave us open to 'orgX just NEVER updates their software,
sheesh!!!'
now, orgX may just disappear from the net periodically: "ok"
so long as orgX isn't 'a.root-servers.net' I guess? :)

3 means yea... a bunch of possible/going-to-bite-us problems about
auto-update...
It's hard to argue for 3 for something that "shouldn't" change that
often (2x/yr per TAL ? :))
and where the total number of 'things changing' is low (5).

The cost to 1 and 2 seem to be: "orgX could fall off the internet,
they'll learn their lesson or not...:("
I'd argue that the 'in software updates with clear warnings to the
updater' is probably safest here,
despite my sre friends screaming about 'automate all the things' :)

> see technology as the barrier here.

ok, so.. if you author types think it's read to put back on the WGLC
menu, let's do that after today/tomorrow's meeting?

---

From: Robert Kisteleki <[email-masked]>
Date: Tue, 28 Apr 2020 09:43:20 +0200

> despite my sre friends screaming about 'automate all the things' :)

The middle-ground solution was also described: the sw can detect the TAL
change (for example by periodically comparing its local version with the
officially published one) and whine if there's a difference. This lets
all kinds of bells going off even in the absence of auto-update (of the
software). And to keep SREs happy :) it can have an option to just
auto-update when there's a change.

Cheers,
Robert