Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 7/11/19 2:55 PM, Michael Richardson wrote:
> EXECSUM: Please stop beating us up for having solved the problem that the WG
>           charter said we we should solve, and for having not solved a
>           problem that the WG charter said was out-of-scope.


I apologize if the objection came off as harsh. My intention was to be 
clear, and that may have come off as more blunt as intended. I 
understand that there's a problem to be solved here, and I think there's 
a fairly simple solution that would satisfy the points I raise (at 
least, to the extent that the IETF can do so).


> Adam Roach via Datatracker <[e-mail]> wrote:
>      > In short, beyond the user-hostile effects of these two issues, I have
>      > ethical issues with the IETF publishing a protocol that promotes the
>      > unnecessary creation of e-waste; and, unless handled properly, that will
>      > be the inevitable result of the two factors I cite above.
>
> I really hate e-waste.  More than many, I think.
>
> I have worked very hard in my spare time in years past on projects like
> cyanogen (when it was a thing) to continue to support perfectly good phones
> that were abandonned by their manufacturers.
>
> Much of the effort of supporting these phones has been because there is no
> protocol for the manufacturers to pass on the real ownership keys to the
> physical owner.   BRSKI can do exactly this.
>
>    *** but manufacturers have to want to do it ***


I completely agree with everything you just said, and sincerely thank 
you for the work you've done in this area. I think where our 
perspectives might diverge is our beliefs about what *we*, the IETF, can 
do about it in this specific case.

The IETF, as a matter of practice, includes normative statements in 
documents all the time regarding processes that conformant 
implementations "MUST" follow for the sake of security. In many cases, 
the protocol works just fine if implementors ignore these requirements, 
which means that implementation of them resolves to exactly one thing: 
manufacturers have to want to do it.

We have no enforcement, and frequently no means to easily detect of 
violations of these normative statements. And yet we make them. And we 
give them normative force. And this allows customers, researchers, and 
even in some cases regulators to use those statements as a stick to try 
to get vendors to behave.

The smallest change that would satisfy my concern would be a statement 
that says that devices conformant to this specification MUST contain a 
local means of bootstrapping that does not rely on any specific server 
being available. As with the security requirements we write into our 
specs, we'll have no means of enforcement. But as with the security 
requirements we write into our specs, we'll give interested parties just 
that little bit more leverage that might tip the scales towards the 
correct behavior.

That's all I'm asking for.


[snip]

> So I totally understand and agree with your reluctance: if BRSKI gets into
> residential IoT, in the fly-by-night vendors that ship crap and then shut
> down, then I agree that it could be pretty user and environmentally hostile.
> Do I think that will happen?  No: the fly-by-night vendors can't keep
> their telnetd debug ports closed, and they aren't going to implement BRSKI
> until such time as it's just there without them knowing it, and they start
> buying IoT system platforms from Intel/ARM/Microsoft/etc.


I'm not worried about fly-by-night vendors. I'm worried about 
acquisition of extremely reputable medium-sized businesses by one of the 
several behemoth vendors who, as a matter of policy, give newly acquired 
business units exactly one year to show >$1MUSD net profit per 
engineering head or be shut down.

/a