Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)

[Toerless Eckert <[e-mail]>]

On Tue, Nov 03, 2020 at 02:01:25PM -0500, Michael Richardson wrote:
>    tte> My TivoHD for example had its certificate expire few years into its lifetime,
>    tte> even though i had upfront bought a so-called "lifetime service" for it.
>    tte> Of course, the lifetime-service did not include "maintaining a current cert for the
>    tte> lifetime of the device".
> 
> What did the certificate do?
> Was this part of an HTTPS management system, or did it allow it to connect
> back to some cloud service?

I don't know whether or not it was used to connect to the cloud service. I would
assume it didn, i should have wiresharked this. It was used for (legal, TiVO permitted ;-)
https download of recordings, so the box became logically unusable for the intended
purpose (download recordings for watching later on a different device).

>    tte> I am saying the IETF is partially to blame because i think we also proliferate
>    tte> the notion that certificates have to be renewed periodically with maximum
>    tte> usual lifetimes of now i think one year ? (was two years)
> 
> That's not the IETF making this policy, this is the CABForum.org, and this is
> driven mostly be browser manufacturer.  All security is a circle.

IETF also had its own opinion about X.5xx and those standards RFC are now
industry standards overriding X.5xx, so why not about this lifecycle managment ?
something like iotops would be a possible place to do this for such type of
consumer/... devices. But not precluding other IETF WG.

>    tte> Of course, this is specifically a consumer-IoT problem, because industrial
>    tte> customers should typically be in a stronger position to avoid these vendor
>    tte> abuse of principally sound technical guidance.
> 
> You'd think so.
> The IETF can't really fix specific problems, but what we can do is provide
> names for processes that allow people/enterprises to take ownership of their
> devices.

Right. Process / proces-profile BCP.

Remember my slides showing Homer Simpson as the registrar ? That level of
abstraction process definitions might help (if need be without home ;-)

>    tte> The fact alone that we do only have in browsers one single TA space (Internet)
>    tte> seems to be the worst offender, proliferated by the fact that that is the
>    tte> only domain that most big contributors in the IETF are interested in.
>    tte> Nevertheless, to support what we classically did without crypto, namely
>    tte> private networks (with private addresses), we should also have a crypto
>    tte> strategy for such private networks. And in most cases, lifetime-long certs
>    tte> will be the only reasonable solution there.
> 
> I am imagining a IoT-specific browser.
> It would have a different set of trust anchors.
> It would NEVER be able to talk to facebook or your bank.
> It would instead have a set of IoT trust anchors, and/or a federation of
> them.

Yes, different TA realms is a very good design starting points for different
network domains that need to be isolated from each other at the end-to-eend layer.

Whether is a same browser or new tabs (white=internet, black=internet-"anonymous",
red="private-network") is IMHO secondary. I do agree though that a browser
for a lot of iot management cases could be a lot smaller than an Internet browser,
so it would fit itself easier into embedded devices itself and be a lot more
reliable and predictable in its page rendering than all the horrenduously
complex options-galore W3C has produced for "The Internet TA realm".


> At this level, it can probably be done as a browser profile without changing much code.
> (The 382 day limit seems to not apply to additional trust anchors)
> 
> Where we get into trouble, I think, is where you need to load content from
> multiple places.  > For instance, what if your device references jQuery from a CDN?
> What if you want to use OAUTH2 to login to your device as authorized by a
> cloud system?

I for once would appreciate if my home gateway would be a TLS proxy that can
see the actual payload passed between my home IoT devices and the cloud. Especially
to allow ME to PERVASIVELY MONITOR what all those iot devices do to the cloud.
Aka: Only this monitoring/filtering TLS proxy would be given TA to both realms
on either side. I am quite certain that most if not all of industrial device
security policies would expect to have an equivalent level of security policy
rquirements. Just the protocols (TLS) would be different for them. Like at
least 20 variations of MQTT brokers instead of TLS proxies or the like.

I highlighted specific words because i think iot operations in IOT will get nowhere
unless it becomes clear that such functions are mandatory for many iot use cases,
and i can't wrap my head around why not every contributor already sees them as
crucial for their own personal use of networking.

The iotops charter for example also does not talk about data management for
iot devices. This type of security operations would fall into that type
of charter point.

> We don't have Cu (CoAP support)in Firefox anymore, because one can't write
> new schemes as extensions due to security architecture changes.

Ok, i don't get that.

>    tte> But, and to get back to the topic: One way on how to get to lifetime-long
>    tte> certs would be an actual transfer of ownership from whaever the vendor
>    tte> put in as certs to a cert from the current owner and using a lifelong
>    tte> expiry time (e.g.: infinite). This could be hosted in a private TA.
>    tte> The question is primarily how to have browsers support different TA
>    tte> domains without confusing the user.
> 
> I was thinking about this, and I come back to wondering if one thing that
> could be done is to have a completely different scheme for IoT devices.
> It would be "https", but with different rules about how it may reference
> other resources.   To first order, COAPS does this, but not exactly.

Somebody more tortured by the variety of iot relevant device to cloud protocols
should give an overview of all the stuff that will stay relevant and would
be within scope of IETF. I would suspect that https/coap are reall just a
smaller subset of what is relevant, so for a BCP or process document it
would initiallybe more important to identify those protocols and see what scheme
of evolution for multiple TA realms might equally work across them instead
try to figure out a one-off solution for one protocol. Of course, experimentation
on any individual protocol is highyl welcome, it just shouldn't be taken
as a suggested general principle unless we know it can map to other protocols.

> On my desktop, I use chrome for most things, but I use a specific firefox
> profile for banking and financial matters.   I think that we need more of
> this: the various "incognito" moves go one direction (removing identity and
> interaction for certain transactions).

Yepp. And with those huge browser we have today, i would really like to
use something like containers to create disjoint running instances with safely
isolated-from-each other profiles. Instead of trusting the browsers to keep
those profiles apart.

Alas, never started to see how difficult it would be to install multiple
instances of e.g. chrome via docker. But foremost one would need a way
to sufficiently influence look&feel of each instance to be differnt
(color scheme of borders or the like).

> We need another direction, super-cognito mode, where additional identity
> information is available.   But, then we also need lateral movements,
> where I can substitute my "work" identity easily for my "home owner" identity.

IN L3VN we developed the notion of RD and RT to express partial overlap
of "reachability". I am sure if we want to shoot ourselves security wise into
the feet with complex partially overlapping TA realms/imports into context
and the like, we can steal a lot from L3VPN ;-))

>    tte> And of course, when you sell the device, you would need to do transfer
>    tte> of ownership again by overwriting the current cert with one of the
>    tte> new owner.
> 
> Qin Wu <[e-mail]> wrote some comments:
> 
>    Qin> Not sure lifetime long certs is a good idea. I feel it is more
>    Qin> vulnerable.
> 
>    Qin> Also I think the current cert doesn't need to be overwritten by cert
>    Qin> of the new owner. The current Cert can be embedded in the Cert of new
>    Qin> owner, see delegation voucher
> 
> The delegation voucher provides a history of ownership.
> But, that isn't the device's certificate, it's the manufacturer's statement.
> I don't see how we can use delegated-voucher to augment the LDevID, except by
> replacing it.

When we discussed BRSKI and change of ownership in the past years it was
always mitigated through the MASA and therefore vendor. I think that is an
important option. I would like to see the option of being able to do this without
any vendor/MASA involvement of course too. I don't think it would be a problem to
define suh a process, but i really would prefer we would define those
workflows abstract first so they're not stuck in a specific protocol like BRSKI,
but could more esily be proliferated across various protocols faster.

aka: for the least difficult to implement "sell-on-ebay" option, you as the
outgoing owner could create a bearer token, and send that in email to the ebay buyer and in parallel
ship the product. Then the receiving new owner could take ownership. But the
vendor should not be able to dis-own the product unless you as the owner
explicitly create a bearer-token.   --- just as an example.

A device could keep track of prior owner LDevID/TA or not ... different issue.

Cheers
    Toerless
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide



> -- 
> Iotops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iotops


-- 
---
[e-mail]