TD Signatures, Key Management, and Object Security

[mmccool]

When/if we have signatures, should discuss when/how they should be used. Could be added to the "object security" section (signatures basically provide object security for metadata). Object security also needs implementation experience and a better set of recommendations.

Consensus: keep the current object security section but add an editor's note saying it is "under construction".

[mmccool]

In general, though, the "object security" section is troublesome since we have no direct experience implementing a system with it, so have not fleshed out all the details. For example, do we need to add parameters to contentType to indicate that an encrypted payload is present? Does the data schema need to be expanded with a type for signatures? Do we need an example that shows how a signature can be carried in a payload? Etc.

So maybe we should just remove this section for now... although it is an important topic. In general we should look at the standards here and ensure we can model their requirements (e.g. header options, etc) in a TD. If we remove it for the first publication, we should make an effort to update this (informative) document before year-end. We could also just add an editor's note "under construction" (@Citrullin likes this latter idea - so let's do that).

[mmccool]

At this point, will start with an editor's note and will do what cleanup I can (e.g. mention TD sigs). Later, in July, Oliver Pfaff will do a cleanup pass, so we will leave this issue open even after my updates. Will target a second update with Oliver's edits.

[OliverPfaff]

Please note: would be able to do some ironing on this after July 1 on (will be on vacation June 04-30)

[mmccool]

OK, created the PR that at least adds the ednote.

[mmccool]

Created a PR to add the ed note, but will keep this issue open for other improvements to this section.

[mmccool]

Still need a PR to address the issues mentioned in the ed note (and ideally, to remove the ed note). Assigning @OliverPfaff

[mmccool]

In particular, I think we need to review JOSE/COSE and object security, and see how it relates to directories and Discovery (a TD Directory is basically a Thing with object security...). Key management is needed for TLS; but this is transport security. Signatures need keys, but public keys (and there are ways to embed or reference the keys from inside the object). What we haven't dealt with yet are encrypted payloads (including TDs). CA can be used for key management for all of these but only if the device has (a) a publically visible URL (b) is on the internet. So the real problem are use cases that don't satisfy a and/or b.

[mmccool]

See plan for signatures under wot-thing-description repo: w3c/wot-thing-description#1151. Current plan is to make this a separate document and use it as an extension, so in theory the "EJS" (encapsulated JSON signature) might also be useful for data returned by an IoT device...

[ashimura]

As I responded to the TD issue #1151, I've created a dedicated repo (wot-ejs) to put the content on Enveloped JSON Signatures spun off from the WoT Security Best Practices document.

[mmccool]

@ashimura thx for creating the repo. I will be copying over the current content shortly to it. And to be clearer, the initial content is to be spun off from w3c/wot-thing-description#1151, which has been closed without merging.

[ashimura]

ah, sorry. just fixed the "About" section and the README.md of the wot-ejs repo accordingly :)

[mmccool]

Note that EJS covers the use case where the sig is embedded in the content. We should also look at supporting "external" signatures using JWS/JOSE in Things, including TDDs. I would suggest for TDs that we sign (using JWS) the Canonical TD form in TDDs, for instance.

[mmccool]

Key management is also the blocking problem in secure local transport, as discussed in #13. One possible resolution mentioned there is to use DID as a means to distribute keys. I am marking issues we should discuss in a joint call with DID with the DID label so we can easily add them to a joint call agenda.

[mmccool]

Some of these topics were discussed in the joint DID/T2TRG call during the F2F: https://www.w3.org/2021/10/28-wot-minutes.html
Summary and some conclusions:

1. TLS does work locally, as long as an identity can be confirmed for an endpoint. A public URL (using DNS, which avoids duplicate registrations) does this but a hardware key and a derived ID could also be used on a LAN. mDNS (e.g. .local names) do not since they can be easily spoofed. (To do: check BREWSKI; there might be a means to combine mDNS, hardware keys, and encryption to generate unspoofable names).
2. However, currently browsers only support publicly-visible URLs (e.g. registered in DNS) for HTTPS; they will not open HTTPS with .local names. DID may provide other solutions in the future but support for DID in browsers is currently uncertain (see https://msporny.github.io/did-core-formal-objections/). Using hardware ids to generate unspoofable names might also work in the future but the key is any solution needs to be supported by browsers.

Suggested actions:

1. Best WoT practice should be to use TLS for all WoT things when using HTTP/TCP (and all other protocols, or the equivalent, e.g. DTLS for CoAP/UDP). Otherwise almost all other security measures are vulnerable.
2. For non-browsers operating on a LAN, e.g. hubs talking to devices, they can use an onboarding process or some other mechanism to establish device identities/trust and set up secure connections. To Do: consider some specific recommendations for this case, e.g. BRSKI.
3. Some systems do not support secure local access (for example, currently, browsers), and have to use a public URL. This needs to be exposed via DNS, e.g. via a cloud proxy or a server URL exposed through the ISP and firewall using STUN/TURN and/or DyDNS. However, this should be limited to a small number of "remote access points", e.g. to a hub dashboard.
4. Add a recommendation that the number of public URLs should be minimized. This is to minimize the attack surface for remote attacks to devices that are eas(ier) to update.
5. Add a best practice that there should be a mechanism to support secure updates. To Do: look at SUIT, recommend it (or provide it as an example; equivalent endor-specific mechanisms would be acceptable)