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

[Christopher Morrow <[e-mail]>]

On Mon, Apr 27, 2020 at 6:26 PM George Michaelson <[e-mail]> wrote:
>
> 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.

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' :)

> 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.

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?