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 <nore...@ietf.org> 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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
