05:36:47 RRSAgent has joined #local 05:36:47 logging to http://www.w3.org/2015/10/28-local-irc 05:36:57 rrsagent, generate minutes 05:36:57 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html joesteele 05:37:00 timeless has joined #local 05:37:10 RRSAgent, draft logs 05:37:10 I'm logging. I don't understand 'draft logs', timeless. Try /msg RRSAgent help 05:37:17 RRSAgent, draft minutes 05:37:17 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html timeless 05:37:22 RRSAgent, make logs world 05:37:23 RRSAgent, draft minutes 05:37:23 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html timeless 05:37:54 meeting: Secure communication with local network devices 05:38:02 chair: mwatson 05:38:06 present+ Giri_Mandyam 05:38:07 scribe: joesteele 05:38:10 igarashi_ has joined #local 05:38:11 present + joesteele 05:38:19 youenn has joined #local 05:38:23 chair: markw 05:38:26 chair: markw 05:38:27 markw has joined #local 05:38:32 present+ markw 05:38:46 scribe: timeless 05:39:03 markw: thanks for coming 05:39:08 ... I put this session on the agenda 05:39:13 ... we encountered this problem in a specific form 05:39:17 ... there's a general form of the problem 05:39:25 ... purpose is to say "hey, there's this problem" 05:39:32 rrsagent, generate minutes 05:39:32 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html joesteele 05:39:37 ... not to say "we have a specific solution" 05:39:45 ... it's very much a get the discussion started 05:39:51 akitsugu has joined #local 05:39:53 ... open it up for people to work on it 05:39:56 ... narrow problem statement 05:40:02 ... applicable specifically to us @netflix 05:40:05 ... user is @home 05:40:13 ... have netflix on tv and device 05:40:18 ... we want to control one device from the other 05:40:25 ... we can do it from a phone 05:40:30 ... but how to do it from a web site? 05:40:37 ... second screen should allow this... 05:40:44 ... stacks raise problems... 05:40:57 ... in due course we'll be secure origin (http://www.netflix.com) 05:41:03 ... DIAL (discover and dial) 05:41:09 s/http/https/ 05:41:11 ... TV has DIAL server (netflix app running there) 05:41:15 ... multicast discovery 05:41:24 ... user to select tv to connect 05:41:29 ... websocket between laptop and tv 05:41:37 s/tv/netflix app on tv 05:41:48 ... open whether site creates socket, or DIAL does it 05:41:52 ... an open issue 05:42:03 ... DIAL is insecure (Multicast) 05:42:09 ... Websocket must be secure 05:42:13 ... otherwise it's mixed content 05:42:18 ... central problem from migrating 05:42:21 ... all or nothing 05:42:23 satoshin has joined #local 05:42:32 ... everything or you don't get the green lock 05:42:39 ... how do we secure the connection? 05:42:54 ... more general problem, device on LAN, lots of random devices on LAN 05:43:04 ... you want to communicate between app on laptop and things 05:43:09 ... websocket/xhr/webrtc 05:43:16 ... connect to https://www.site.com 05:43:21 ... more general version of same problem 05:43:31 ... Key issue: distribution of responsibility for determining what's secure 05:43:42 ... application should secure communication with its peer 05:43:51 ... that needs to happen, but app doesn't display padlock 05:43:55 ... browser displays padlock 05:44:02 ... browser has to assure itself that communication is secure 05:44:06 ... how to arrange this? 05:44:17 ... what does the browser need to know about communication between site and device? 05:44:25 ... currently the 2 criteria are: 05:44:34 ... 1 endpoint must be identified by name by the site 05:44:47 ... normally an XHR to an endpoint (named) 05:45:00 ... 2 same origin or CORS-same-origin with the site 05:45:07 ... user says "i trust the site" 05:45:18 ... implicitly "i trust anyone netflix trusts" 05:45:19 rus has joined #local 05:45:27 ... our backend server could do stuff 05:45:34 ... it's extended to cross origin 05:45:46 ... also, CORS-same-origin says that the other site is ok w/ netflix talking to it 05:46:11 josepe: there's also a mixed content 05:46:19 ... not even communicate at all? 05:46:27 markw: same thing... 05:46:35 s/josepe/giuseppe 05:47:01 ... the reason something is mixed content is that it doesn't meet the bar promising to the user a security level 05:47:08 ... we have to think over what that promise is 05:47:10 hfujisa__ has joined #local 05:47:14 gmandyam: in the drawing 05:47:26 ... mixed content was in the Multicast discovery 05:47:37 ... I thought mixed content was part of the web page 05:47:47 markw: discover is fine, it's like DNS, DNS is insecure 05:48:21 mfoltz: the browser is asserting that the server is the server and the connection is encrypted 05:48:27 gmandyam: the issue is that the ... 05:48:39 markw: if the web socket isn't secure, then you have mixed content 05:48:50 mfoltz: in this context, discovery isn't directly exposed to the page 05:49:20 [ Scribe explains minutes are wrong for the picture ] 05:49:46 markw: immediate problem is that "out of the box", endpoints do not have certificates chained to a public root of trust 05:49:54 ... if you knew that, chained to dns, you'd be fine 05:50:00 ... obvious one is cloud mediated 05:50:08 s/one/solution/ 05:50:20 ... issues are latency 05:50:35 ... throughput is the min of the two paths (up+down-link on your connection) 05:50:41 ... media streaming 05:50:49 ... also doesn't solve discovery 05:51:01 ... cloud mediated requires me to program each device to log into its device 05:51:13 gmandyam: IoT, how's this work? 05:51:38 markw: the server has a web server w/ certificate 05:51:48 ... the IoT doesn't have its own ssl certificate 05:52:02 mfoltz: there's a step missing here 05:52:10 ... IoT device needs to advertise a token 05:52:25 markw: there needs to be some roundeavuz to register w/ your account 05:54:01 Josh_Soref has joined #local 05:54:22 Josh_Soref: Plex has the cloud to answer the connection 05:54:31 mfoltz: and now plex issues certs to each device 05:54:42 minami_ has joined #local 05:55:01 markw: if you can register names in dns, then you're ok 05:55:11 ... issues w/ this include how scalable is that, millions of certs/devices 05:55:22 ... is dns fine w/ entries for these millions of devices 05:55:29 ... this is my candidate to experiment in earnest 05:55:37 ... doesn't really solve discovery 05:55:46 ... cloud mediation requires both sides to register w/ cloud 05:56:01 https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ 05:56:12 tidoust has joined #local 05:56:40 mfoltz: there are fully qualified certs with a wildcard 05:56:47 ... per user 05:56:56 ... client figures out ip of server 05:57:00 markw: it's pretty neat 05:57:06 ... certificate binds name to device 05:57:11 ... you find right ip through dns 05:57:21 Josh_Soref: they blogged this idea 05:57:32 markw: i suppose we should see that the idea isn't mired in IPR 05:57:52 markw: then, w/ DIAL you could do the same w/ discovery to find the name for the device on the local network 05:58:02 ... multicast discovers devices, presentation lets user choose 05:58:06 ... DIAL provides name back to UA 05:58:22 ... UA establishes websocket, or gives name to website which makes its normal connection 05:58:33 MarkVickers: so each device has its own cert? 05:58:36 markw: yes 05:58:59 markw: not sure there's a tractable thing for the server 05:59:09 ... i guess DIAL server could have a range of ... 05:59:22 mfoltz: if TLS is per app, then server per app 05:59:26 markw: we could do that today 05:59:35 ... if we wanted the server in DIAL server, that's part of the platform 05:59:39 MarkVickers: you could do that if ... 05:59:44 markw: you launch with DIAL 06:00:17 ... another possible thing to look at is TLS Public Key 06:00:20 ... you don't have names 06:00:25 ... if that were supported in browsers 06:00:36 ... the problem would be to get the key from the device to the website 06:00:39 ... you could do by cloud mediation 06:02:07 ZZ: it could be symmetric key instead of public key, right? 06:02:08 markw: yes 06:02:45 mfoltz: this requires IoT device to talk to cloud service to get a public key for that address 06:02:45 ... you need to know that that device is that device and not just leaching 06:02:52 markw: general problem 06:02:53 s/ZZ/joesteele/ 06:03:08 mfoltz: before you have this secure channel, how do you provide netflix credentials? 06:03:18 markw: you probably have prebaked public key 06:03:53 Josh_Soref: NFC/QR/BT could establish a way to set credentials 06:04:23 markw: the other option is TLS Public Key + Pairing Ceremony + Multicast Discovery 06:04:32 ... this is probably the most assurance that it's the one you wanted 06:04:37 ... QR/NFC 06:04:59 mfoltz: chromium supported SPEAKE2 using a PIN to facilitate public-private key exchange 06:05:02 ... we use it for chrome-remote-desktop 06:05:10 s/SPEAKE2/SPAKE2 06:05:10 ... we don't have a way to expose that to web applications 06:05:18 ... an action item is a way to expose that to applications 06:05:27 ... to create this kind of trust relationship 06:05:45 Josh_Soref: I think Firefox mobile tried to do that and gave up 06:06:02 markw: impractical way is to show public key on one 06:06:06 joesteele: it could be a QR code 06:06:16 markw: or even a small hash of a public key 06:06:25 ... get to a way to simply do this 06:06:40 ... the point of the hash is that there's a user involved 06:07:05 SSQ: first example, 1. user trusts netflix ; netflix talks to a lot of things; 2. netflix wants to talk to the right device 06:07:16 ... we don't generally want a website to talk to everything on your network 06:07:36 markw: w/ presentation api, the presentation api on the browser does multicast discovery, shows list to user, site gets only one bit of information 06:07:41 gmandyam: not the general IoT UC 06:08:00 ... there are deployment scenarios where the user doesn't get involved 06:08:07 SSQ: significantly more difficult to deal w/ 06:08:11 markw: I'm out of slides 06:08:15 s/SSQ/mkwst/ 06:08:38 s/SSQ/mkwst/ 06:08:48 Topic: Discussion 06:09:02 gmandyam: netflix is both content server and also the contentn consumer 06:09:14 ... other content distribution models that aren't DIAL might need to be considered 06:09:24 ... making DASH content available through a local server 06:09:29 ... has netflix thought about that? 06:09:39 markw: we use DIAL wherever we put a device in place 06:09:48 ... we haven't thought about streaming from devices other than our own servers 06:09:53 ... we don't have a UC for that 06:10:06 mfoltz: markw , have you communicated this to #webappsec? 06:10:17 markw: yep, i was hoping to have people here from that group? 06:10:20 mkwst: yes 06:10:33 markw: I don't participate in that group, but I or someone from netflix could 06:10:45 mkwst: we talked about the general topic as part of an early draft of Mixed-Content Spec 06:10:55 ... threw that away, it ended up being complicated 06:11:01 ... i had a solution of "block everything" 06:11:05 ... i'm interested in picking it up again 06:11:18 ... deal w/ case where a device on a local network wants to expose itself to the web 06:11:22 ... and let the user mitigate 06:11:36 ... some sort of pairing ceremony, SPAKE or otherwise seems reasonable 06:11:47 ... i find it much more difficult to gmandyam's IoT case 06:11:53 ... that's much more difficult to deal w/ 06:12:02 ... indistinguishable from attack scenario 06:12:10 ... I'm concerned w/ router vulnerabilities 06:12:21 ... all sorts of ways to make routers to do bad things 06:12:43 ... one approach is to block routers to access RFC1918 Internal v. Extenal 06:13:07 ... we define areas of IPv4 "reserved for internal use" 06:13:13 ... not the case that internal stuff is on that 06:13:21 ... but blocking those would get rid of many attacks 06:13:29 ... that's the angle i'm coming to this from 06:13:34 ... totally reasonable to come up w/ pairing 06:13:38 joesteele: isn't pairing, 06:13:45 ... is that problematic when i come home each day 06:13:50 ... do i have to pair each time? 06:13:55 mkwst: i don't think that's necessary 06:14:00 ... UA can act as a mediator 06:14:05 ... UA can figure out what's on the network 06:14:08 ... DIAL or otherwise 06:14:14 ... there's an ID associated w/ that 06:14:28 oonishi has joined #local 06:14:29 ... no reason that UA can't retain memory 06:15:38 ... UA doesn't have to 06:15:50 MarkVickers: can you go back to the Plex solution? 06:16:26 mkwst: I think the plex solution is interesting 06:16:28 ... it's relatively secure 06:16:36 ... bind cert to hash of user id 06:16:43 ... i think the domain name they use is a local domain name 06:16:46 ... plex.something 06:16:52 MarkVickers: not something user is involved 06:17:03 mkwst: looks like normal web server connection 06:17:14 ... i'm concerned about general case of stuff on web talking to thing 06:17:19 ... this secures against local snooping 06:17:28 ... it doesn't solve problem of user granting access to device 06:17:35 ... i think it's a problem, but i don't think it's fatal 06:17:46 gmandyam: when Opera proposed service-discovery 06:17:54 ... everything was exposed 06:18:06 ... your model, user browses to web site, discovery is by UA 06:18:14 mkwst: I think a Chooser model makes a lot of sense 06:18:23 ... directly exposing to the web is a huge privacy violation 06:18:42 ... user involved in choosing exposing device-3 but not letting web site know about devices 4,5,6 is more compelling 06:18:51 MarkVickers: I think device + cloud service are in one 06:18:57 ... you can't use one w/o the other 06:19:08 mkwst: in the plex model, it makes a lot of sense, user has to set up device 06:19:10 ... set up user id 06:19:14 ... user id is unique locally 06:19:20 ... don't connect if you don't configure 06:19:28 markw: this doesn't show discovery 06:19:38 ... in this other case, DIAL lets you do discovery 06:19:54 ... this (DIAL) mode, user chose thing by friendlyname 06:20:00 ... that's insecure 06:20:26 ... all netflix can agree is that "guy i'm talking to is a netflix app, and it has a friendly name, but i don't know it's really the right one" 06:20:34 OOO: problem w/ discovery 06:20:43 ... UPnP DNS has a problem 06:20:55 markw: pairing w/ user typing solves that 06:21:05 gmandyam: user downloaded the netflix app? 06:21:12 markw: or it's preinstalled 06:21:17 gmandyam: user intervention in UA 06:21:39 markw: DNS name is passed up to netflix app, we'll see user picked a name, it's a name we issued cert for 06:21:45 ... website will tell browser to connect to 06:21:50 ... something site approved of 06:21:54 ... need that step 06:22:02 ... otherwise, it could be anyone advertising 06:22:20 gmandyam: post-discovery by UA, site needs to get info 06:22:20 s/OOO:/Igarashi:/ 06:22:46 mfoltz: can you go to "Points in the solution space (3)" 06:22:52 ... there's also the WebRTC security model 06:23:01 ... after peers negotiate path 06:23:13 ... they do DTLS and then expose keys up to browser 06:23:17 ... that's another possible path 06:23:34 ... your implementation is focused around WebSockets, but I think WebRTC could used 06:23:44 ... that allows application to verify identify 06:23:54 ... but there may be a way for browser to do some verification as well 06:24:06 mkwst: we consider WebRTC a secure connection 06:24:16 mkwst: related topic 06:24:24 ... worried about w/ IoT is "updates" 06:24:32 ... we talk about "it's a secure connection" 06:24:38 ... but over time, the definition of Secure changes 06:24:42 ... SHA1, RC4 deprecation 06:24:55 ... it's pretty difficult for us to make these migrations 06:25:01 ... no idea how to make that happen for IoT 06:25:11 markw: big problem for TVs that do not like to update 06:25:24 paulc: "Secure" changes over time 06:25:31 mkwst: 5 years ago, SHA1 was totally secure 06:25:34 ... today, "don't use" 06:25:39 ... tomorrow "SHA2 is terrible" 06:25:47 ... change in computing power available 06:26:06 paulc: brute force is not use these techniques 06:26:19 mkwst: impossible to claim we have a secure connection w/ something we don't consider secure 06:26:28 ... in Jan / Feb, we'll remove RC4 cypher suites 06:26:40 ... those devices will stop being accessible 06:26:47 paulc: w/ time we'll leave more devices behind 06:26:58 mkwst: critical that devices have sane update mechanisms from the start 06:27:10 markw: previously if you didn't update device, its features stayed the same 06:27:16 ... but here, over time the features will degrade 06:27:23 ... because other devices won't talk to you anymore 06:29:13 markw: we know these migrations will happen 06:29:23 ... we need to be more aggressive than we have been in the past 06:29:32 ... we still see people giving pushback 06:29:43 MMM: need a mechanism to update IoT 06:29:54 gmandyam: we produce IoT devices that couldn't handle IoT 06:30:08 markw: you update and it continues to work, or you don't update, and it stops working 06:30:20 ... "would i even ship the feature if i couldn't update the feature" 06:30:30 ... the browsers reasonably changed the security requirements 06:30:35 MarkVickers: non browser things 06:30:40 ... browser communicates w/ web servewr 06:30:44 s/ewr/er 06:30:53 MMM: sony tvs, netflix stopped working after a period of time 06:31:06 NNN: NTSC, ATSC 06:31:11 ... very disruptive, relatively seldom 06:31:18 ... this universe changes really rapidly 06:31:26 ... disruptions that happen a lot will be rejected by consumers 06:31:39 markw: that's why i wouldn't turn the feature on if the tv wasn't updateable 06:31:53 NNN: TVs will be "upgradable", but not powerable to support your feature 06:31:55 s/MMM:/Rus:/g 06:32:02 joesteele: market for product to proxy service 06:32:22 rrsagent, generate minutes 06:32:22 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html joesteele 06:32:32 markw: while tvs could be updatable, they usually only get 1-2 updates 06:32:36 NN: recurring model for IoT 06:32:41 s/NN:/NNN: 06:33:06 mfoltz: if you want to experiment w/ this, try chrome extensions to do SPAKE2 or TLS Public Key 06:33:13 ... to see what the mechanism would look like 06:33:20 ... folks in #webappsec have feedback, be valuable 06:33:23 s/NNN:/Bill_Rose:/g 06:33:27 markw: definitely next step is experimentation 06:33:44 ... we only recently realized there were things that didn't require browser changes 06:33:52 BBB: cross site... 06:34:02 ... PIN pairing 06:34:08 ... would that support cross-origin? 06:34:20 mfoltz: I think regular cors rules would apply 06:34:59 s/BBB/Igarashi 06:35:13 ... we get in trouble 06:35:19 ... if netflix makes a secure connection 06:35:26 ... we're cors ok 06:35:32 ... if we push it behind presentation 06:35:37 ... and browser makes connection on behalf 06:35:42 ... do we try to hack CORS 06:35:50 ... or come up w/ a different mechanism 06:36:02 Josh_Soref: this is exactly the problems Opera had for Discovery 06:36:20 markw: we didn't consider the device serving a web site 06:36:28 mfoltz: it's possible 06:37:01 markw: if user browses to local device 06:37:06 ... can it access the outside world? 06:37:09 mfoltz: maybe 06:37:15 mkwst: today, yes 06:37:36 markw: but if that site tries to access a cors site, and it has an internal ip? 06:37:44 mkwst: today we'd send the IP address as the origin 06:37:48 ... and web site makes a decision 06:37:57 ... no mechanism to decide "good" or "bad" 06:38:11 RRSAgent, draft minutes 06:38:11 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html tidoust 06:38:13 RRSAgent, draft minutes 06:38:13 I have made the request to generate http://www.w3.org/2015/10/28-local-minutes.html timeless 06:39:02 paulc: markw thanks for coming so prepared 06:40:42 hfujisawa has joined #local 06:42:38 hfujisawa has joined #local 06:50:13 kimwooglae has joined #local 06:58:43 hfujisawa has joined #local 06:59:10 oonishi_ has joined #local 06:59:49 hfujisawa has joined #local 07:00:28 oonishi__ has joined #local 07:01:57 oonishi__ has left #local 07:03:12 kimwooglae has joined #local 07:05:40 tidoust has joined #local 07:07:48 akitsugu has joined #local 07:13:38 rus has joined #local 07:39:38 dveditz has joined #local 07:41:50 dveditz has left #local 08:06:05 hfujisaw_ has joined #local 08:11:00 hfujisawa has joined #local 08:14:43 hfujisawa has joined #local 08:16:50 akitsugu has joined #local 08:24:42 hfujisawa has joined #local 08:32:09 rus has joined #local 08:59:18 hfujisawa has joined #local 09:11:47 hfujisawa has joined #local 09:15:24 rus has joined #local 09:17:43 rus_ has joined #local 09:27:22 hfujisawa has joined #local 09:43:08 hfujisawa has joined #local 09:44:06 rus has joined #local 10:13:42 hfujisawa has joined #local 10:34:00 rus has joined #local 10:36:20 hfujisawa has joined #local 11:27:08 rus has joined #local 11:42:43 rus has joined #local 11:58:27 rus has joined #local 12:34:40 rus has joined #local 12:49:10 kimwooglae has joined #local 13:00:02 rus has joined #local 13:23:13 hfujisawa has joined #local 13:41:59 rus has joined #local 14:07:23 tidoust has joined #local 14:07:43 hfujisawa has joined #local 14:07:47 hfujisaw_ has joined #local 14:55:15