> The "soft fail" happens if devices need to be reset to factory > settings for some reason, then you will have to wait for the > manufacturer's servers to bring them back up. when i sell the lightb^Hrouter to mary, of course i reset to factory settings. > That may be mitigated if the manufacturer provided you with nonceless > vouchers, valid until "time=X", and in particular if the manufacturer > gave you vouchers "good until infinity". In that case, your old > devices could still be reset to factory condition and restarted, > without even "soft fail". dear world: be absolutely sure that, when you buy a lightb^Hrouter, you get a nonceless voucher with an infinite lifetime. before handing them your cash, you can test this by .... right how about the spec says that "the manufacturer MUST accompany the lightb^Hrouter with a nonceless voucher with an infinite lifetime. purchasers who, for whatever reason, with more restricted vouchers may negotiate." >> if the manufacturer's servers go down, either permanently or even for >> a day, can i give/sell the device i have purchased to a third, well >> fourth i guess, party, at my whim and seamlessly unencumbered? > > It depends somewhat on the type of voucher that the manufacturer is > willing to give you, but the short answer is No, you can't. > > If the manufacturer only wants to provide real time vouchers that > incorporate the random nonce issued by the device, then the answer is > very clearly no, you cannot resell the device without approval from the > manufacturer. The voucher in that case acts as a kind of DRM. then i strongly object to the ietf specifying this; c.f. selling guns. > If the manufacturer is willing to issue "good until time=X" vouchers, > then in theory you could provide the voucher to your buyer, provided the > time limit of the voucher has not elapsed. If the manufacturer signs a > voucher "good until infinity", then the device can in theory be sold and > resold forever. But that's probably not true in practice, because the > voucher is written for a specific domain, and includes the certificate > of the domain for which the voucher is good. You may be able to play > games with some kind of certificate chain and make it work, but I will > believe that when I see it. i.e. practically you can not resell something you thought you had bought. baaaaaad. > The BRSKI specification is a tradeoff and that's why I would really > like to see the tradeoff explained in clear terms in the spec. It is > designed to prevent hijacking of the device during its registration in > the buyer's network. if, to actually own a device i bought, i need to manage my own security, then i will take that. > If BRSKI implemented a pure RFC 7030 process, the device might have > to accept to be imprinted by the registrar without having verified to > whom it is talking. In practice that would mean relying on some kind > of physical security, or maybe relying on the kind of trust anchors > commonly used for web services. From the registrar point of view, the > failure mode is that some kind of man-in-the-middle inserts itself > during the registration process, and maintains control of the device > after it is connected to the network. > > The voucher system mitigates that risk, but at the cost of strong > dependency on the manufacturer. As I say, that's a trade-off, and I > could see different buyers having different opinions on that > dependency. In fact, I could see buyers willing to buy devices only > if they permitted "voucher-less" initialization. If the standard > allowed that option, then market forces would quickly define how > valuable the voucher system is. two problems. the buyer will not realize that they just rented the lightb^Hrouter until they go to sell it; way too late to do anything about it. the manufactures have very small incentive to lower drm barriers. i can point to a jillion current examples. my favorite of the week is john deere. randy
