- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 10 Jan 2022 17:44:30 +0900
- To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
https://www.w3.org/2021/11/01-wot-sec-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
– DRAFT –
WoT Security
01 November 2021
[2]IRC log.
[2] https://www.w3.org/2021/11/01-wot-sec-irc
Attendees
Present
Kaz_Ashimura, Michael_McCool, Philipp_Blum,
Tomoaki_Mizushima
Regrets
-
Chair
McCool
Scribe
kaz
Contents
1. [3]Minutes review
Meeting minutes
Minutes review
McCool: Oct 18
… also joint meeting with IRTF T2TRG and DID meeting
[4]Oct 18
[4] https://www.w3.org/2021/10/18-wot-sec-minutes.html
[5]Oct 28
[5] https://www.w3.org/2021/10/28-wot-minutes.html
McCool: (goes through the minutes from Oct 28 meeting)
Kaz: (fixes typos, etc.)
(some discussion on IDs within local environment)
McCool: (adds a comment to the GitHub Issue)
[6]wot-security-best-practices issue 14 - TD Signatures, Key
Management, and Object Security
[6] https://github.com/w3c/wot-security-best-practices/issues/14
McCool: suggested actions
… 1. best WoT practice should be to use TLS for all WoT Things
when using HTTP. Otherwise almost all other security measures
are broken.
Philipp: TLS works well without your own key management system
McCool: (adds clarification)
… TLS does work locally, as long as an identity can be
confirmed for an endpoint
… regular DNS is fine
… 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 sine 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
[7]RFC8995 - Bootstrapping Remote Secure Key Infrastructure
(BRSKI)
[7] https://datatracker.ietf.org/doc/html/rfc8995
Philipp: not only for HTTP but also CoAP?
McCool: (adds DTLS for CoAP/UDP in addition to HTTP/TCP)
… suggested action 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 and set up secure
connections.
… To Do: consider some specific recommendations for this case,
e.g., BRSKI
… suggested action 3
… for browser access, they will (currently) have to use a
public URL
… e.g., via a clod proxy or a URL exposed thourhg the ISP and
firewall using STUN/TURN and/or DyDNS.
… ohwever this should be limited to a small number of "remote
access points", e.g., to a hub dashboard.
Philipp: we should have some recommendation
… but should not limit the possible methods to it
McCool: we should clarify best practices
Philipp: ok
McCool: suggested action 4
… add a recommendation that the number of public URLs should be
minimized.
Kaz: technically, we should say "for systems that don't support
secure local access, e.g., browsers currently" instead of
"browsers have to..."
McCool: (adds the modification)
… my question here is that regular IoT devices don't be
regularly updated
Philipp: update is a good point
McCool: should have a best practice to have mechanism to
support secure updates. To Do: look at SUIT.
[8]McCool's comments for Issue 14 based on the discussion today
[8] https://github.com/w3c/wot-security-best-practices/issues/14#issuecomment-956210818
[9]added one line comment to see the above comments to Issue 13
as well
[9] https://github.com/w3c/wot-security-best-practices/issues/13#issuecomment-956212304
McCool: regarding the minutes for item 6 from vF2F Day 5
… and item 7
… item 6 and 7 to be merged, I think
… objections to approve those sections?
(none)
(approved)
[adjourned]
Minutes manually created (not a transcript), formatted by
[10]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[10] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 10 January 2022 08:44:36 UTC