See also: IRC log
<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"
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]