[wot-security] minutes - 26 July 2021

available at:
  https://www.w3.org/2021/07/26-wot-sec-minutes.html

also as text below.

Thanks,

Kazuyuki

---
   [1]W3C

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

                              WoT Security

26 July 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#26_July_2021
      [3] https://www.w3.org/2021/07/26-wot-sec-irc

Attendees

   Present
          Kaz_Ashimura, Michael_McCool, Oliver_Pfaff,
          Philipp_Blum, Tomoaki_Mizushima

   Regrets
          Elena_Reshetova

   Chair
          McCool

   Scribe
          kaz

Contents

    1. [4]Minutes
    2. [5]Meeting schedule in August
    3. [6]Best Practices
         1. [7]Issue 13

Meeting minutes

  Minutes

   [8]July-19

      [8] https://www.w3.org/2021/07/19-wot-sec-minutes.html

   McCool: any objections?

   (none; approved)

  Meeting schedule in August

   McCool: vacation in August
   … starting with the next week
   … and cancel all the Security call in August

   (Aug 2-23 Security meetings will be cancelled)

  Best Practices

    Issue 13

   [9]PR 20 - Cleanup

      [9] https://github.com/w3c/wot-security-best-practices/pull/20

   [10]PR 19 - Add Ed Note to Object Security

     [10] https://github.com/w3c/wot-security-best-practices/pull/19

   [11]PR 21 - Add local TLS/DTLS security via Raw Public Keys

     [11] https://github.com/w3c/wot-security-best-practices/pull/21

   McCool: some clean up PRs as above

   [12]Issue 13 - Update Secure Local Transport

     [12] https://github.com/w3c/wot-security-best-practices/issues/13

   McCool: how to generate a PR for that?

   Oliver: a bit different form of secure transport

   McCool: would like to mention some proxy as well
   … (adds comments to Issue 13)
   … expectations around mutual authentication, etc.
   … would be useful to distinguish "key distribution" from
   "secure transport"
   … but we have to decide where certain parts go, e.g., mutual
   authentication
   … also question of managing permissions

   Oliver: would look into the NETCONF RFCs
   … 6241

   [13]RFC6241

     [13] https://datatracker.ietf.org/doc/html/rfc6241

   [14]more specifically, section 2.2

     [14] https://datatracker.ietf.org/doc/html/rfc6241#section-2.2

   Oliver: talks about authentication
   … meant for network configuration, not specifically for Web
   … there is also RESTCONF

   [15]RFC8040

     [15] https://datatracker.ietf.org/doc/html/rfc8040

   McCool: anonymous service for IoT

   Oliver: you'd like to learn NETCONF for encryption, etc.
   … similar constraints like the ones we have

   McCool: original intent of Philipp was to support a secure PKS
   key distribution
   … typically we see the key during the onboarding process
   … would assume something like OAuth for tokens
   … some kind of mechanism for people to access multiple devices
   … but how do you know who to generate the token, and how to get
   it?

   Philipp: also what kind of clients are available
   … core issue here is how to distribute the keys

   McCool: yeah
   … want to be able to target the problem of a larg number of
   users and devices
   … also being able to manage different/dynamic permissions for
   different users
   … want to avoid configuration for each device every time
   … we should look into standards on key distribution
   … or at least de-facto mechanism
   … are there an existing best practices?
   … CA is one such system but requries that servers have a public
   URL
   … LDAP is another possibility but that is just a distributed
   directory; CAN hod keys

   Oliver: LDAP is basically a directory and doesn't handle
   security itself
   … but you can run LDAP over TLS

   McCool: what we want to do is not recommending something new
   but unusual

   <citrullin> [16]https://datatracker.ietf.org/doc/html/
   rfc7250#section-1

     [16] https://datatracker.ietf.org/doc/html/rfc7250#section-1

   McCool: we'd like to see the existing best practices
   … what do people actually use?
   … (found a research paper about key management)

   [17]Towards Formally Verified Key Management for Industrial
   Control Systems

     [17] https://dl.acm.org/doi/10.1145/3372020.3391555

   McCool: probably should define some terms
   … and then some suitable options for different "modules"
   … e.g., for secure transport and for key distribution
   … problem with TLS 1.2 is can't use raw public keys...

   Oliver: raw public key was available before. will check the
   specification again

   McCool: use cases for browsers
   … accessing public URLs
   … relate to how we deal with proxies, tunnels, etc.
   … also reverse/forward proxies

   <citrullin> [18]https://success.qualys.com/discussions/s/
   question/0D52L00004TnvRc/
   using-raw-public-keys-in-transport-layer-security-tls-and-datag
   ram-transport-layer-security-dtls

     [18] https://success.qualys.com/discussions/s/question/0D52L00004TnvRc/using-raw-public-keys-in-transport-layer-security-tls-and-datagram-transport-layer-security-dtls

   <citrullin> [19]https://bugzilla.mozilla.org/
   show_bug.cgi?id=1050175

     [19] https://bugzilla.mozilla.org/show_bug.cgi?id=1050175

   McCool: perhaps we simply say "if you want to access a system
   though a browser, nee to access system via a public URL secured
   by a certificate."
   … then we simply have to discuss the privacy implications

   [20]McCool's comments

     [20] https://github.com/w3c/wot-security-best-practices/issues/13#issuecomment-886673831

   Philipp: gave some resources above
   … the first link above is about Using Raw Public Keys in TLS
   and DTLS

   (which mentions Firefox nightly supports client side TLS 1.3

   McCool: (adds another comment to Issue 13)
   … some browsers may support import of raw public keys and/or
   integration with PS systems
   … if one exists, then we can give this as an option in
   environments where putting public URLs for access devices is
   not desirable.

   [adjourned]


    Minutes manually created (not a transcript), formatted by
    [21]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

     [21] https://w3c.github.io/scribe2/scribedoc.html

Received on Monday, 20 September 2021 11:00:38 UTC