[wot-security] minutes - 1 November 2021

available at:

also as text below.




      [1] https://www.w3.org/

                             íV DRAFT íV
                              WoT Security

01 November 2021

   [2]IRC log.

      [2] https://www.w3.org/2021/11/01-wot-sec-irc


          Kaz_Ashimura, Michael_McCool, Philipp_Blum,





    1. [3]Minutes review

Meeting minutes

  Minutes review

   McCool: Oct 18
   íK 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
   íK 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)
   íK TLS does work locally, as long as an identity can be
   confirmed for an endpoint
   íK regular DNS is fine
   íK 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
   íK mDNS (e.g., .local names) do not sine they can be easily
   íK 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

      [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)
   íK suggested action 2
   íK 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
   íK To Do: consider some specific recommendations for this case,
   e.g., BRSKI
   íK suggested action 3
   íK for browser access, they will (currently) have to use a
   public URL
   íK e.g., via a clod proxy or a URL exposed thourhg the ISP and
   firewall using STUN/TURN and/or DyDNS.
   íK 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
   íK but should not limit the possible methods to it

   McCool: we should clarify best practices

   Philipp: ok

   McCool: suggested action 4
   íK add a recommendation that the number of public URLs should be

   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)
   íK 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
   íK and item 7
   íK item 6 and 7 to be merged, I think
   íK objections to approve those sections?




    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