On 9/30/2018 11:52 AM, Randy Bush wrote: > christian, > > a stunning review as usual. but i have two questions which you kind of > finessed. they are simple binary, i.e. yes/no, questions that the end > user, to whom the IETF is ultimately responsible, really cares about. > > if the manufacturer's servers go down, either permanently or even for > a day, does the device i have purchased still work? i.e. is it fail > soft? [0] My understanding is that, yes, the device that you have purchased and installed still works. BRSKI is a bootstrap service, and as Michael Richardson says, the dependency is only there during the bootstrap, i.e. between the time you unwrap the device and the time initialization on your network is complete. 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. 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". > > 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. 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. > fwiw, i asked these same questions at the 2005 paris side meeting at > l'ecole whatever hosted by mark. the blank stares i received alarmed > me. the ietf is ultimately responsible to the users. 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 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. -- Christian Huitema
