Secure communication with local network devices

28 Oct 2015

See also: IRC log


Giri_Mandyam, joesteele, markw
joesteele, timeless


<joesteele> scribe: joesteele

<timeless> chair: markw

<scribe> chair: markw

<timeless> scribe: timeless

markw: thanks for coming
... I put this session on the agenda
... we encountered this problem in a specific form
... there's a general form of the problem
... purpose is to say "hey, there's this problem"
... not to say "we have a specific solution"
... it's very much a get the discussion started
... open it up for people to work on it
... narrow problem statement
... applicable specifically to us @netflix
... user is @home
... have netflix on tv and device
... we want to control one device from the other
... we can do it from a phone
... but how to do it from a web site?
... second screen should allow this...
... stacks raise problems...
... in due course we'll be secure origin (https://www.netflix.com)
... DIAL (discover and dial)
... TV has DIAL server (netflix app running there)
... multicast discovery
... user to select tv to connect
... websocket between laptop and netflix app on tv
... open whether site creates socket, or DIAL does it
... an open issue
... DIAL is insecure (Multicast)
... Websocket must be secure
... otherwise it's mixed content
... central problem from migrating
... all or nothing
... everything or you don't get the green lock
... how do we secure the connection?
... more general problem, device on LAN, lots of random devices on LAN
... you want to communicate between app on laptop and things
... websocket/xhr/webrtc
... connect to https://www.site.com
... more general version of same problem
... Key issue: distribution of responsibility for determining what's secure
... application should secure communication with its peer
... that needs to happen, but app doesn't display padlock
... browser displays padlock
... browser has to assure itself that communication is secure
... how to arrange this?
... what does the browser need to know about communication between site and device?
... currently the 2 criteria are:
... 1 endpoint must be identified by name by the site
... normally an XHR to an endpoint (named)
... 2 same origin or CORS-same-origin with the site
... user says "i trust the site"
... implicitly "i trust anyone netflix trusts"
... our backend server could do stuff
... it's extended to cross origin
... also, CORS-same-origin says that the other site is ok w/ netflix talking to it

giuseppe: there's also a mixed content
... not even communicate at all?

markw: same thing...
... the reason something is mixed content is that it doesn't meet the bar promising to the user a security level
... we have to think over what that promise is

gmandyam: in the drawing
... mixed content was in the Multicast discovery
... I thought mixed content was part of the web page

markw: discover is fine, it's like DNS, DNS is insecure

mfoltz: the browser is asserting that the server is the server and the connection is encrypted

gmandyam: the issue is that the ...

markw: if the web socket isn't secure, then you have mixed content

mfoltz: in this context, discovery isn't directly exposed to the page

[ Scribe explains minutes are wrong for the picture ]

markw: immediate problem is that "out of the box", endpoints do not have certificates chained to a public root of trust
... if you knew that, chained to dns, you'd be fine
... obvious solution is cloud mediated
... issues are latency
... throughput is the min of the two paths (up+down-link on your connection)
... media streaming
... also doesn't solve discovery
... cloud mediated requires me to program each device to log into its device

gmandyam: IoT, how's this work?

markw: the server has a web server w/ certificate
... the IoT doesn't have its own ssl certificate

mfoltz: there's a step missing here
... IoT device needs to advertise a token

markw: there needs to be some roundeavuz to register w/ your account

Josh_Soref: Plex has the cloud to answer the connection

mfoltz: and now plex issues certs to each device

markw: if you can register names in dns, then you're ok
... issues w/ this include how scalable is that, millions of certs/devices
... is dns fine w/ entries for these millions of devices
... this is my candidate to experiment in earnest
... doesn't really solve discovery
... cloud mediation requires both sides to register w/ cloud

<mkwst> https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

mfoltz: there are fully qualified certs with a wildcard
... per user
... client figures out ip of server

markw: it's pretty neat
... certificate binds name to device
... you find right ip through dns

Josh_Soref: they blogged this idea

markw: i suppose we should see that the idea isn't mired in IPR
... then, w/ DIAL you could do the same w/ discovery to find the name for the device on the local network
... multicast discovers devices, presentation lets user choose
... DIAL provides name back to UA
... UA establishes websocket, or gives name to website which makes its normal connection

MarkVickers: so each device has its own cert?

markw: yes
... not sure there's a tractable thing for the server
... i guess DIAL server could have a range of ...

mfoltz: if TLS is per app, then server per app

markw: we could do that today
... if we wanted the server in DIAL server, that's part of the platform

MarkVickers: you could do that if ...

markw: you launch with DIAL
... another possible thing to look at is TLS Public Key
... you don't have names
... if that were supported in browsers
... the problem would be to get the key from the device to the website
... you could do by cloud mediation

joesteele: it could be symmetric key instead of public key, right?

markw: yes

mfoltz: this requires IoT device to talk to cloud service to get a public key for that address
... you need to know that that device is that device and not just leaching

markw: general problem

mfoltz: before you have this secure channel, how do you provide netflix credentials?

markw: you probably have prebaked public key

Josh_Soref: NFC/QR/BT could establish a way to set credentials

markw: the other option is TLS Public Key + Pairing Ceremony + Multicast Discovery
... this is probably the most assurance that it's the one you wanted
... QR/NFC

mfoltz: chromium supported SPAKE2 using a PIN to facilitate public-private key exchange
... we use it for chrome-remote-desktop
... we don't have a way to expose that to web applications
... an action item is a way to expose that to applications
... to create this kind of trust relationship

Josh_Soref: I think Firefox mobile tried to do that and gave up

markw: impractical way is to show public key on one

joesteele: it could be a QR code

markw: or even a small hash of a public key
... get to a way to simply do this
... the point of the hash is that there's a user involved

mkwst: first example, 1. user trusts netflix ; netflix talks to a lot of things; 2. netflix wants to talk to the right device
... we don't generally want a website to talk to everything on your network

markw: w/ presentation api, the presentation api on the browser does multicast discovery, shows list to user, site gets only one bit of information

gmandyam: not the general IoT UC
... there are deployment scenarios where the user doesn't get involved

mkwst: significantly more difficult to deal w/

markw: I'm out of slides


gmandyam: netflix is both content server and also the contentn consumer
... other content distribution models that aren't DIAL might need to be considered
... making DASH content available through a local server
... has netflix thought about that?

markw: we use DIAL wherever we put a device in place
... we haven't thought about streaming from devices other than our own servers
... we don't have a UC for that

mfoltz: markw , have you communicated this to #webappsec?

markw: yep, i was hoping to have people here from that group?

mkwst: yes

markw: I don't participate in that group, but I or someone from netflix could

mkwst: we talked about the general topic as part of an early draft of Mixed-Content Spec
... threw that away, it ended up being complicated
... i had a solution of "block everything"
... i'm interested in picking it up again
... deal w/ case where a device on a local network wants to expose itself to the web
... and let the user mitigate
... some sort of pairing ceremony, SPAKE or otherwise seems reasonable
... i find it much more difficult to gmandyam's IoT case
... that's much more difficult to deal w/
... indistinguishable from attack scenario
... I'm concerned w/ router vulnerabilities
... all sorts of ways to make routers to do bad things
... one approach is to block routers to access RFC1918 Internal v. Extenal
... we define areas of IPv4 "reserved for internal use"
... not the case that internal stuff is on that
... but blocking those would get rid of many attacks
... that's the angle i'm coming to this from
... totally reasonable to come up w/ pairing

joesteele: isn't pairing,
... is that problematic when i come home each day
... do i have to pair each time?

mkwst: i don't think that's necessary
... UA can act as a mediator
... UA can figure out what's on the network
... DIAL or otherwise
... there's an ID associated w/ that
... no reason that UA can't retain memory
... UA doesn't have to

MarkVickers: can you go back to the Plex solution?

mkwst: I think the plex solution is interesting
... it's relatively secure
... bind cert to hash of user id
... i think the domain name they use is a local domain name
... plex.something

MarkVickers: not something user is involved

mkwst: looks like normal web server connection
... i'm concerned about general case of stuff on web talking to thing
... this secures against local snooping
... it doesn't solve problem of user granting access to device
... i think it's a problem, but i don't think it's fatal

gmandyam: when Opera proposed service-discovery
... everything was exposed
... your model, user browses to web site, discovery is by UA

mkwst: I think a Chooser model makes a lot of sense
... directly exposing to the web is a huge privacy violation
... user involved in choosing exposing device-3 but not letting web site know about devices 4,5,6 is more compelling

MarkVickers: I think device + cloud service are in one
... you can't use one w/o the other

mkwst: in the plex model, it makes a lot of sense, user has to set up device
... set up user id
... user id is unique locally
... don't connect if you don't configure

markw: this doesn't show discovery
... in this other case, DIAL lets you do discovery
... this (DIAL) mode, user chose thing by friendlyname
... that's insecure
... 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"

Igarashi: problem w/ discovery
... UPnP DNS has a problem

markw: pairing w/ user typing solves that

gmandyam: user downloaded the netflix app?

markw: or it's preinstalled

gmandyam: user intervention in UA

markw: DNS name is passed up to netflix app, we'll see user picked a name, it's a name we issued cert for
... website will tell browser to connect to
... something site approved of
... need that step
... otherwise, it could be anyone advertising

gmandyam: post-discovery by UA, site needs to get info

mfoltz: can you go to "Points in the solution space (3)"
... there's also the WebRTC security model
... after peers negotiate path
... they do DTLS and then expose keys up to browser
... that's another possible path
... your implementation is focused around WebSockets, but I think WebRTC could used
... that allows application to verify identify
... but there may be a way for browser to do some verification as well

mkwst: we consider WebRTC a secure connection
... related topic
... worried about w/ IoT is "updates"
... we talk about "it's a secure connection"
... but over time, the definition of Secure changes
... SHA1, RC4 deprecation
... it's pretty difficult for us to make these migrations
... no idea how to make that happen for IoT

markw: big problem for TVs that do not like to update

paulc: "Secure" changes over time

mkwst: 5 years ago, SHA1 was totally secure
... today, "don't use"
... tomorrow "SHA2 is terrible"
... change in computing power available

paulc: brute force is not use these techniques

mkwst: impossible to claim we have a secure connection w/ something we don't consider secure
... in Jan / Feb, we'll remove RC4 cypher suites
... those devices will stop being accessible

paulc: w/ time we'll leave more devices behind

mkwst: critical that devices have sane update mechanisms from the start

markw: previously if you didn't update device, its features stayed the same
... but here, over time the features will degrade
... because other devices won't talk to you anymore
... we know these migrations will happen
... we need to be more aggressive than we have been in the past
... we still see people giving pushback

Rus: need a mechanism to update IoT

gmandyam: we produce IoT devices that couldn't handle IoT

markw: you update and it continues to work, or you don't update, and it stops working
... "would i even ship the feature if i couldn't update the feature"
... the browsers reasonably changed the security requirements

MarkVickers: non browser things
... browser communicates w/ web server

Rus: sony tvs, netflix stopped working after a period of time

Bill_Rose: NTSC, ATSC
... very disruptive, relatively seldom
... this universe changes really rapidly
... disruptions that happen a lot will be rejected by consumers

markw: that's why i wouldn't turn the feature on if the tv wasn't updateable

Bill_Rose: TVs will be "upgradable", but not powerable to support your feature

joesteele: market for product to proxy service

markw: while tvs could be updatable, they usually only get 1-2 updates

Bill_Rose: recurring model for IoT

mfoltz: if you want to experiment w/ this, try chrome extensions to do SPAKE2 or TLS Public Key
... to see what the mechanism would look like
... folks in #webappsec have feedback, be valuable

markw: definitely next step is experimentation
... we only recently realized there were things that didn't require browser changes

Igarashi: cross site...
... PIN pairing
... would that support cross-origin?

mfoltz: I think regular cors rules would apply
... we get in trouble
... if netflix makes a secure connection
... we're cors ok
... if we push it behind presentation
... and browser makes connection on behalf
... do we try to hack CORS
... or come up w/ a different mechanism

Josh_Soref: this is exactly the problems Opera had for Discovery

markw: we didn't consider the device serving a web site

mfoltz: it's possible

markw: if user browses to local device
... can it access the outside world?

mfoltz: maybe

mkwst: today, yes

markw: but if that site tries to access a cors site, and it has an internal ip?

mkwst: today we'd send the IP address as the origin
... and web site makes a decision
... no mechanism to decide "good" or "bad"

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/28 06:38:16 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/http/https/
Succeeded: s/tv/netflix app on tv/
Succeeded: s/josepe/giuseppe/
Succeeded: s/one/solution/
Succeeded: s/ZZ/joesteele/
Succeeded: s/SPEAKE2/SPAKE2/
Succeeded: s/SSQ/mkwst/
Succeeded: s/SSQ/mkwst/
Succeeded: s/OOO:/Igarashi:/
Succeeded: s/ewr/er/
Succeeded: s/MMM:/Rus:/g
Succeeded: s/NN:/NNN:/
Succeeded: s/NNN:/Bill_Rose:/g
Succeeded: s/BBB/Igarashi/
Found Scribe: joesteele
Inferring ScribeNick: joesteele
Found Scribe: timeless
Inferring ScribeNick: timeless
Scribes: joesteele, timeless
ScribeNicks: joesteele, timeless
Present: Giri_Mandyam joesteele markw
Got date from IRC log name: 28 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/28-local-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]