> On 16 Jul 2019, at 15:57, Joel M. Halpern <j...@joelhalpern.com> wrote: > > I can't tell from this whether you agree that it is reasonable to put in some > mechanism to address this issue?
I think I do because I proposed such a mechanism up thread. Eliot > > Yours, > Joel > > On 7/16/2019 9:40 AM, Eliot Lear wrote: >> Hi Joel, >>> On 16 Jul 2019, at 14:59, Joel Halpern Direct <jmh.dir...@joelhalpern.com> >>> wrote: >>> >>> I am having trouble connecting your reply with my request. >>> Let's take the direct issue first, and then the analogy. >>> >>> I had suggested a specific enhancement to device behavior. The response >>> was "but that removes the theft protection." It is that form of theft >>> protection that I am objecting to. As far as I can tell, the mechanism I >>> suggested does not break zero touch. It allows someone who controls their >>> network, and who physically controls a new device, to put that new device >>> in their network without asking anyone's permission. >>> It does not permit someone with a device, but not network control, from >>> adding that device to the network. It does not permit someone with control >>> of the network, but not physical access to the device, to achieve anything >>> special. So it seems compatible with the goals. >> My apologies I took your statement as something more general than you >> intended. With respect to this from earlier: >>> I have assumed that what we needed is the ability for a buyer, who has >>> physical possession of the device, and possibly some simple (non >>> cryptographic) credentials provided by the seller to force the device to >>> reset what it thinks it is part of, and to emit in some accessible form the >>> information the buyer needs to be able to make this device part of his >>> network, using his authentication servers, etc. >> That was indeed what we discussed. We just got into means a bit more than >> perhaps necessary. I’ll point out that it’s always going to be a >> manufacturer call on how best to do this; and how to transport credentials, >> and how to keep them safe, even. >>> >>> In terms of the analogy, I would have problem with IEtF defining a new >>> protocol that added significant risk to the buyer when they buy from new >>> vendors. >>> And existing vendors do go out of businesses. And vendors do end-of-life >>> products. (You can't get a new key to your car because the vendor has >>> stopped supporting that model???) >> I wouldn’t implement a 1:1 mapping products->MASA server function. That >> seems excessive. And rare is the case when a vendor EOLs a product and then >> cripples it through an update mechanism. The only issue here is whether a >> database entry would stay around. >>> >>> Now it may be that the particular approach I suggested won't work. But it >>> seems to me that there needs to be a way for folks to keep using, and to >>> keep re-selling, devices without the support of the vendor. That usage may >>> not get all the zero-touch advantages that supported re-sale would get. >>> But it has to work. And putting the onus for that on the original vendor >>> does NOT seem an effective solution. >> I think you mean, “requiring the vendor to stay around for ever doesn’t seem >> like an effective solution.” Again, I don’t want to overgeneralize. >> Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
