12:03:38 RRSAgent has joined #wot-sec 12:03:38 logging to https://www.w3.org/2021/07/26-wot-sec-irc 12:04:00 meeting: WoT Security 12:04:17 present+ Kaz_Ashimura, Michael_McCool, Oliver_Pfaff, Philipp_Blum 12:04:26 chair: McCool 12:04:52 agenda: https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#26_July_2021 12:04:59 present+ Tomoaki_Mizushima 12:05:17 regrets+ Elena_Reshetova 12:06:11 scribenick: kaz 12:06:40 topic: Minutes 12:06:49 -> https://www.w3.org/2021/07/19-wot-sec-minutes.html July-19 12:08:45 mm: any objections? 12:08:50 (none; approved) 12:09:11 topic: Meeting schedule in August 12:09:20 mm: vacation in August 12:09:33 ... starting with the next week 12:09:48 ... and cancel all the Security call in August 12:10:13 (Aug 2-23 Security meetings will be cancelled) 12:10:45 topic: Best Practices 12:10:49 subtopic: PR 13 12:11:29 s/13/20/ 12:11:52 -> https://github.com/w3c/wot-security-best-practices/pull/20 PR 20 - Cleanup 12:12:24 -> https://github.com/w3c/wot-security-best-practices/pull/19 PR 19 - Add Ed Note to Object Security 12:12:47 -> https://github.com/w3c/wot-security-best-practices/pull/21 PR 21 - Add local TLS/DTLS security via Raw Public Keys 12:13:08 s/PR 20/Issue 13/ 12:13:18 mm: some clean up PRs as above 12:13:45 -> https://github.com/w3c/wot-security-best-practices/issues/13 Issue 13 - Update Secure Local Transport 12:14:00 mm: how to generate a PR for that? 12:14:30 op: a bit different form of secure transport 12:15:04 mm: would like to mention some proxy as well 12:15:16 ... (adds comments to Issue 13) 12:16:07 ... expectations around mutual authentication, etc. 12:16:43 ... would be useful to distinguish "key distribution" from "secure transport" 12:17:17 ... but we have to decide where certain parts go, e.g., mutual authentication 12:17:28 ... also question of managing permissions 12:17:53 op: would look into the NETCONF RFCs 12:18:02 ... 6241 12:18:31 -> https://datatracker.ietf.org/doc/html/rfc6241 RFC6241 12:19:17 -> https://datatracker.ietf.org/doc/html/rfc6241#section-2.2 more specifically, section 2.2 12:19:40 op: talks about authentication 12:20:18 ... meant for network configuration, not specifically for Web 12:20:35 ... there is also RESTCONF 12:21:09 -> https://datatracker.ietf.org/doc/html/rfc8040 RFC8040 12:21:49 mm: anonymous service for IoT 12:22:09 op: you'd like to learn NETCONF for encryption, etc. 12:22:41 ... similar constraints like the ones we have 12:24:37 mm: original intent of Philipp was to support a secure PKS key distribution 12:25:15 ... typically we see the key during the onboarding process 12:25:33 ... would assume something like OAuth for tokens 12:26:02 ... some kind of mechanism for people to access multiple device 12:26:06 s/device/devices/ 12:26:24 ... but how do you know who to generate the token, and how to get it? 12:27:06 pb: also what kind of clients are available 12:27:19 ... core issue here is how to distribute the keys 12:27:32 mm: yeah 12:27:47 ... want to be able to target the problem of a larg number of users and devices 12:28:07 ... also being able to manage different/dynamic permissions for different users 12:28:37 ... want to avoid configuration for each device every time 12:29:03 ... we should look into standards on key distribution 12:29:37 ... or at least de-facto mechanism 12:30:17 ... are there an existing best practices? 12:31:38 ... CA is one such system but requries that servers have a public URL 12:32:34 ... LDAP is another possibility but that is just a distributed directory; CAN hod keys 12:32:53 op: LDAP is basically a directory and doesn't handle security itself 12:34:17 ... but you can run LDAP over TLS 12:35:12 mm: what we want to do is not recommending something new but unusual 12:35:24 https://datatracker.ietf.org/doc/html/rfc7250#section-1 12:35:30 mm: we'd like to see the existing best practices 12:35:44 ... what do people actually use? 12:38:32 ... (found a research paper about key management) 12:38:51 -> https://dl.acm.org/doi/10.1145/3372020.3391555 Towards Formally Verified Key Management for Industrial Control Systems 12:39:10 mm: probably should define some terms 12:39:22 ... and then some suitable options for different "modules" 12:39:31 ... e.g., for secure transport and for key distribution 12:41:42 ... problem with TLS 1.2 is can't use raw public keys... 12:43:58 op: raw public key was available before. will check the specification again 12:44:20 mm: use cases for browsers 12:44:31 ... accessing public URLs 12:46:38 ... relate to how we deal with proxies, tunnels, etc. 12:46:52 ... also reverse/forward proxies 12:47:20 https://success.qualys.com/discussions/s/question/0D52L00004TnvRc/using-raw-public-keys-in-transport-layer-security-tls-and-datagram-transport-layer-security-dtls 12:47:29 https://bugzilla.mozilla.org/show_bug.cgi?id=1050175 12:49:19 mm: 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." 12:49:30 ... then we simply have to discuss the privacy implications 12:51:54 -> https://github.com/w3c/wot-security-best-practices/issues/13#issuecomment-886673831 McCool's comments 12:52:28 pb: gave some resources above 12:54:13 ... the first link above is about Using Raw Public Keys in TLS and DTLS 12:55:33 (which mentions Firefox nightly supports client side TLS 1.3 12:55:57 mm: (adds another comment to Issue 13) 12:56:27 ... some browsers may support import of raw public keys and/or integration with PS systems 12:57:16 ... if one exists, then we can give this as an option in environments where putting public URLs for access devices is not desirable. 12:58:31 [adjourned] 12:58:35 rrsagent, make log public 12:58:39 rrsagent, draft minutes 12:58:39 I have made the request to generate https://www.w3.org/2021/07/26-wot-sec-minutes.html kaz 13:00:03 s/PR 20/Issue 13/ 13:00:09 rrsagent, draft minutes 13:00:09 I have made the request to generate https://www.w3.org/2021/07/26-wot-sec-minutes.html kaz 14:22:55 Zakim has left #wot-sec