[Christian, read down a ways]
On 22.10.18 20:15, Michael Richardson wrote: > Eliot, thanks for this document. If nothing else, it means that > we BRSKI authors can deal with some review comments by pointing to "future > work" :-) > > (A)"request-voucher-with-possession" <-- what about intent to traffic? :-) > (for those that don't get the joke: > > https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html > ) > > if leaf out-of-band-claim to be set by the PLEDGE? > I think it is set by the Registar? In all cases, any out of band claim has to be collected by the Registrar. It is possible that having received such a claim from the Registrar, the pledge forwards it along to the MASA. > > The document sadly ends too soon... Gosh. You want it all at once, don' you?! Become an editor ;-) > > You say it is trying to do a few things. > 1) deal with middle value pledge, > (and low-value pledges in very congested places) > where an out-of-band supply-chain integration is unavailable, > and the MASA has a any-registar policy for the device. Yes. > > 2) provide a ship-and-forget mechanism. Yes. > > It seems that the cryptographic POP mechanism is an ends to accomplish a > means, rather than a core goal of the protocol. I never employ hashes just for fun ;-) > The Pledge already can > sign it's voucher-request, and since it includes the Registrar's key when it > does a proximity assertion, it's pretty good proof of possession for the > *Registrar*, but it might provide inadequate assurance to the MASA of it's > freshness. I think this covers the Joe Isuzu case that can fall out of the draft, and maybe one other. The fundamental issue with the others is that the Pledge needs some reason to believe that it is really on the correct network. Proof of possession can come in several forms, depending on the device, but we're assuming that there's no user input to the device available (e.g., no buttons, to touch screen, etc). It could also be that the Pledge really doesn't want to validate proof of possession by itself. In that case, there's no reason for the pledge to even know the proof of possession. > If the MASA could provide a nonce for the pledge to sign > (requiring another round trip, and even more online assurance), that would > provide even more proof. > > Given that you pushed this out before today's cutoff, I am not upset > that there is so few details. I am suspecting that in your thinking that you > created the three objects, and realized that could accomplish > "ship-and-forget" using a combination of them? That's part of the thinking, yes. > > I also wonder if cryptographic-POP is being confused with "proof of > ownership", which I think is what you really want to accomplish. We can have that discussion . > > If one assumes some machine readable (QR) code that comes with the product, > then there are a few things one can do to differently. One of the things > that I have thought a lot about is that one uses the printed code in the > Registrar to establish a relationship with the MASA. That is, one creates > the supply-chain-integration by using the QR code with some zero-knowledge > proof (I think that PAKE is the latest one) to establish that one is the > legitimate Registrar for the product. One can do this as *any time* > (some mumble about the lifetime of the CA of the Registrar's key), and > the product will be enrolled correctly at any future time. Good point. One possible thought in terms of the evolution of this work would be “More stuff you can do with vouchers” with a plethora of documented uses. Or we might want to spawn a few more drafts. Again, worth discussion. > > About my joke (A) above, I think that ship-and-forget is an interesting > goal, and in particular, if also may enable desireable "traffic"ing. That > is, if the manufacturer can transfer the product to my ownership without any > online interaction, then presumably, I can also *resell* the device to > you using the same lack-of-interaction? Yes. In fact that is a goal that I think both Christian and Randy have motivated. I would want to explore a bit whether or not to split out ship and forget, but I would rather we tried to solve for that problem because it really is here (see below). > > ==== > > > In addition, some manufacturers may prefer not to require the > > existence of a MASA. In these circumstances proof of possession to > > the device is required. > > I would prefer that we split this into a different draft. > > I am very concerned that ship-and-forget is not a desireable property > in the IoT space. It essentially means that the manufacturer has no further > interest in providing any kind of updates for the device. I have serious > cybersecurity concerns about such devices being out there (sitting unpatched > and untracked in a warehouse somewhere), as well as significant environmental > concerns about devices designed to die like this. It could also be the case that the device is intended to be deployed in disconnected environments. I also think it's going to be a little while before certain classes of manufacturers will seriously be able to run an online MASA. And I would like them to at least be able to consume a voucher, even if we need different sorts of transfer approaches. > > I am trying to think of devices where this makes sense. I come up with a few > things: single-use medical devices (like bandages, syringes, etc.), > prophylactics and other single-use sex toys, things you eat, and some > variety of devices that might be called "spy craft". In each case, I'm > having difficulty knowing what the "smart" aspect of the product is, other > than simply tracking it's existence and current stocking location. A smart > package containing a dumb device is a good idea, but it seems like something > that would be better recycled, and in any case, it's not ship-and-forget > for the packaging. > > So this is why I think that splitting ship-and-forget mechanism into another > document would let us treat it better. In particular, I want to know who is > going to deploy using such mechanisms, and if they are at the table now. > I guess I shall add a slide to my ANIMA BRSKI stack about this in an attempt > to get feedback. > > I suspect that there is a category of devices that some think of being > ship-and-forget which might actually be ship-to-holding-company. > Holding company leases to end user for period of time. End user identity > is never communicated back, and might be very much pseudonymous. > I'm thinking about car-rentals, hotel rooms (full of devices), ... > > Let's discuss further. Looking forward to the Tuesday 6:00pm Side meeting. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
