{cutting CC of people, and we need to pick a WG list to discuss this on?}

Eliot Lear <[email protected]> wrote:
    >> 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.

https://en.wikipedia.org/wiki/Joe_Isuzu  ... I asked google, and I'm not
quite sure I get the connection.

    >> 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.

It's not enough to say that they are going to be deployed in disconnected
environments.  It's that they one wants to drop-ship them from the
*manufacturers* warehouse to the disconnected location.

When one thinks about drop-ship to a disconnected location, one tends to
think about containers of humanitarian AID going out the back of a aircraft
(C-2, Hercules, etc.) with a parachute.   If anything, that situation is
probably *NOT* the case we are thinking about, because in that case the kit
would have already gone through the owner's warehouse (whether the owner is
a UN aid agency, some FEMA equivalent).  The entire kit could have been
onboarded (wirelessly) as it went *onto* the aircraft, or could even occur
as late as when it's on the aircraft.

And you said, "online MASA", when it could well be that it's an offline
MASA.  If you buy enough product, the manufacturer could well just put
a custom trust anchor in and give you the private key.  That's essentially
what happens in Industrial 4.0 802.15.4 deployments today.

So I'm saying, let's not invent a problem before we understand who actually
has the problem.... and make sure that the people who can solve the problem
are at our table.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu

Reply via email to