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

[George Michaelson <[e-mail]>]

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