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

[Robert Kisteleki <[e-mail]>]

On 2020-03-04 09:55, Tim Bruijnzeels wrote:
> 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.

Hi,

Thank you Tim for your thoughts. I do agree that more discussion is
warranted about pros/cons for this approach. Perhaps a wider threat
modelling would be useful.

Speaking for myself only: I believe that at the end of the day the
in-band approach the draft proposes has more downsides than upsides.
YMMV. Now, if there weren't alternative approaches, then I'd also say
"it addresses a perceived problem so why not?" -- but there *are*
real-life alternatives. George reiterated a few:

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

(BTW I did not suggest this :-)

>> Or, a signalling mechanism to flag "this TAL needs to change" but the
>> actual decision to change, is hand-managed buy the RP.

My ordering would put (3) on top, closely followed by (1).

(3) has many upsides: it can warn the operator if there's a TAL change
*even if* the software is otherwise not upgraded. This allows the
operator to do a manual double-check if that's desired. It even allows
an automatic update (I imagine it can be a RP software option). In other
words, it makes it the operators' decision to do the update in-band or not.

(1) is an example of how a mechanism for achieving comparable outcomes
works really well in a different context, on a much bigger scale. It
also leaves the operator in full control, if that's desired.


All in all, I'm not against this draft per se. But I do want to make
sure we consider if it provides the best approach to the problem.

Robert