07:19:10 RRSAgent has joined #webscreens 07:19:10 logging to https://www.w3.org/2018/05/17-webscreens-irc 07:19:32 RRSAgent, make logs public 07:19:38 Meeting: Second Screen WG/CG F2F - Day 1/2 07:19:41 Chair: Anssi 07:19:48 Agenda: https://www.w3.org/wiki/Second_Screen/Meetings/May_2018_F2F#Agenda 07:19:52 Present+ Anssi_Kostiainen, Mark_Foltz, Brandon_Tolsch, Louay_Bassbouss, Hyojin_Song, Tatsuya_Igarashi, Chris_Needham, Francois_Daoust, Stephan_Steglich 07:20:24 Zakim has joined #webscreens 07:22:20 scribenick: tidoust 07:22:48 igarashi has joined #webscreens 07:23:26 Anssi: Welcome! WG + CG meeting. The WG has delivered more or less what it was to. Focus will be more on the CG part. Mark and Brandon prepared an agenda with a number of issues to go through. 07:23:49 ... Those topics were touched during our last F2F at TPAC last year. 07:25:09 ... [going through the agenda] 07:27:02 mfoltzgoogle: Re. the API, we've done a little bit of work on the local window mode idea, happy to share progress on Friday afternoon 07:27:59 Local presentation mode issue: https://github.com/w3c/presentation-api/issues/347 07:29:08 Updated explainer link: https://github.com/mfoltzgoogle/local-presentation-api/blob/gh-pages/explainer.md 07:30:04 Topic: Introductions 07:30:48 anssik: Working for Intel. Chairing the Second Screen CG/WG. Also the Device and Sensors WG. Working with our Chromium contributors. We want to write specs and work on implementations. 07:31:50 mfoltzgoogle: Work on Chrome, for Google. 3 years in the group. Editor of the Presentation API. My team, including Brandon and others, have been implementing this API in Chrome, liaising with other teams to make the API better for them. 07:32:13 btolsch: Working for Google. First time in W3C. Implementing the specs, integration with Cast. 07:32:57 Louay: Working for Fraunhofer FOKUS. Been in the group since day 1. Also doing multi-screen more generically, and other streaming use cases, such as 360 videos. 07:33:44 hyojin: Representing LGE. Involved in various groups at W3C. LG devices use Chromium, we don't have cast-enabled function for now, so interested in the open screen protocol 07:34:28 igarashi: Work for Sony. AC representative. Also involved in other interactive TV SDOs, including Hybridcast, ATSC 3.0. 07:34:59 ... Not a member of the group, but interested to understand how this activity relates to companion screen features in other standards and whether they can align. 07:35:48 ... This kind of API could be useful for broadcast standards. Also, personally, I was involved in home network technology such as DLNA. Involved in the HTTPS in Local Network CG. 07:36:05 ... Securing the local network is a missing technology for now. 07:37:25 cpn_: Work for BBC. Look at new technologies for audio and videos. New formats, new experiences. I co-chair the Media & Entertainment Interest Group. 07:38:04 ... We have interest from two points of view here: for our iplayer to launch video to a cast device, but also in aligning with HbbTV. 07:38:22 scribenick: cpn_ 07:38:56 Francois: Team contact of the group, and Media & Entertainment Champion 07:38:56 Francois: I work for W3C as the Media & Entertainment champion, looking at what we do and could be doing at W3C 07:39:17 scribenick: tidoust 07:39:34 stepsteg: Work for Fraunhofer FOKUS as Louay. Happy to host the meeting of the group here! 07:40:01 Topic: Agenda bashing 07:40:18 -> https://docs.google.com/document/d/1p6VSnG46FwHKZgM80Xf7gFekKV_HGeGFwDnEfitipDY/view Proposed agenda 07:41:45 anssik: [going through topics]. For discovery, we discussed 3 different methods last time, suggesting both mDNS and SSDP be supported. 07:42:17 mfoltzgoogle: Mostly, what I have prepared is data about our dual discovery implementation in Chrome and use that data to inform the discussion 07:43:08 anssik: are people happy to collect data from implementations and base design decisions on that data? 07:43:29 [no objection] 07:43:49 anssik: For transport, we raised QUIC last time 07:44:20 mfoltzgoogle: Yes, we agreed to take a deeper dive at what it would take to use the QUIC data channel. 07:44:56 ... To support that on top of WebRTC-based transport. Direct UDP, or using ICE. We've looked at the different scenarios. 07:45:16 ... Also looked at leveraging the QUIC protocol to support the application command protocol that we need for the API. 07:46:05 ... TLS1.3 is still being worked upon. But it's close to being interoperable, I believe. 07:46:27 cpn_: I think there was some recent announcement at IETF about TLS 1.3 07:46:46 ... I can take the issue that was assigned to Shih-Chiang 07:47:06 mfoltzgoogle: I'll talk a bit about the bootstrapping mechanism. 07:47:49 anssik: First one for today is transport security and authentication. I think you have a proposal and Tomoyuki has some slides about J-PAKE. 07:48:15 mfoltzgoogle: Have some background material. Part of the proposal is to use J-PAKE indeed. Then we can talk about next steps. 07:48:54 cpn_: Is there something we can report back from the HTTPS in Local Network CG that could inform the discussion? 07:49:26 anssik: Right, Igarashi-san and Tomoyuki can jump in discussions as needed. 07:53:08 -> https://www.w3.org/community/httpslocal/ HTTPS in Local Network Community Group 07:53:36 Topic: Background overview 07:54:49 mfoltzgoogle: [presenting slides] 07:56:04 ... People here should be somewhat familiar with the history of the API, but I'll go quickly through it. We went through agenda bashing, we'll go into a bit more of details in technical aspects. 07:56:58 ... On day 2, Brandon will lead the discussion on the control protocol. We have some data to share for that serialization and recommendation on how to move forward. Also HbbTV/ATSC compatibility. 07:57:49 ... Also, my team is working on an open source implementation of the Open Screen Protocol, discussion on next steps. 07:58:00 ... Starting with some background material 07:58:38 ... [Showing timeline]. Started in Nov 2013, I think. 07:59:32 anssik: Yes, it started in a breakout session at TPAC there. Some browser vendors showed interest at the time, and we quickly started incubation 08:00:40 mfoltzgoogle: The API was incubated in the CG, and then transitioned to a WG. At that point, the CG no longer had much to do, until it appeared clearly that interoperability was a major issue to look at. 08:01:12 ... CG rechartered to work on interoperability. 08:02:02 anssik: We should credit the TAG. They submitted their feedback that they wanted to see interoperability at the protocol layer. So we did our homework, and here we are. Mozilla was also strongly pushing for that. 08:03:19 mfoltzgoogle: Making progress on the Open Screen Protocol since then. The WG was rechartered, and progress on the APIs is more tied up to progress on the Open Screen Protocol. 08:03:51 ... To publish the Presentation API as a Rec, we'll need to demonstrate interoperability based on the Open Screen Protocol across browsers and devices. 08:03:54 -> https://www.w3.org/TR/presentation-api/#candidate-recommendation-exit-criteria Presentation API Candidate Recommendation exit criteria 08:04:54 ... At a high level, for the Presentation API, a controlling page (in a browser) wants to present content on a second screen (connected or not to the first one). 08:05:43 ... The page requests presentation. The browser lists compatible display, prompts the user to choose one. If successful, the browser creates a communication channel with the receiver, and loads the presentation there. 08:06:00 ... The controlling page can then exchange with the receiving page. 08:06:26 igarashi: What happens when one end closes the connection? 08:06:46 mfoltzgoogle: Both ends can close the connection at any time. This does not kill the page on either end. 08:07:18 hyojin: Are multiple connections possible? 08:07:35 mfoltzgoogle: Yes. Two tabs on the same controlling browser can connect to the same presentation. 08:07:50 ... Or different pages running on different devices, potentially. 08:08:06 Louay: Also, one controller can launch multiple presentations. 08:08:48 mfoltzgoogle: Correct. With the same URL, if the user chooses a different device for the second request, this creates a separate connection. 08:09:01 ... I don't think we have sample code for one controller to multiple devices case. 08:09:58 ... To implement this API, the controlling user-agent can do two different things: in the 2-UA mode, the browser sends the URL of the presentation to the receiving device, which renders it. 08:10:23 ... In this case, the user-agent rendering the controlling page is distinct from the user-agent rendering the receiving page. 08:10:39 ... They only share commands through the application channel 08:11:16 ... The other scenario is when the devices are connected by wire/wireless media 08:11:48 ... In that case, the controlling browser also renders the receiving page locally, and passes the rendered content to the receiving display. 08:12:33 ... It can be wired displays, we recently added support for that in Chrome: if you connect a second display, it can be the target of the Presentation API. 08:12:45 anssik: Useful to point out that this is not in scope of the Open Screen Protocol. 08:13:21 mfoltzgoogle: The second API that we developed is the Remote Playback API, where a controlling page can request playback of a media element to a second screen. 08:13:55 ... Media commands get forwarded to the remote playback device. The concepts are similar to the Presentation API, but you can only exchange media commands. 08:14:36 anssik: It's interesting to note that all other browsers implement that feature on their chrome for now: Edge, Apple, Firefox for Android. 08:15:34 Louay: Any requirement for synchronization? The currentTime needs to be synchronized with the current time in the receiving side. 08:16:01 mfoltzgoogle: We haven't yet defined the requirements for the Open Screen Protocol for the Remote Playback API. Latency should be one of them. 08:16:06 -> https://github.com/webscreens/openscreenprotocol/issues/3 Requirements: Remote Playback API 08:16:21 anssik: Suggest that you mention that in the related issue, Louay! 08:16:56 mfoltzgoogle: I can show some demos over coffee break. 08:18:03 ... We have shipped support for these APIs. Presentation controller shipped in May 2016. We also shipped support for cloud browser to launch a presentation on another instance of Chrome. 08:18:42 ... The Presentation receiver part (1-UA) was launched in June 2017. Allows to send presentation to a Cast device. 08:18:43 -> https://bugzil.la/1184036 Mozilla 1-UA support for Presentation API 08:19:00 -> https://bugzil.la/1184073 Mozilla 2-UA support for Presentation API 08:19:59 ... Remote Playback also shipped on Android in February 2017. On desktop, we don't have full support for the API right now, but we're shipping a remote media feature soon, so hopefully we'll have full support later on. 08:20:34 anssik: If people have contacts at Mozilla, it would be good to have their explicit feedback on implementation of the APIs. 08:20:49 ... The Presentation API is mentioned on Edge Status. 08:21:08 ... As for Apple, I think that they are very interested in the Remote Playback API. 08:21:33 s/shipped in May 2016/(2-UA) shipped in May 2016/ 08:22:05 igarashi: Will Android applications support that protocol? 08:23:38 mfoltzgoogle: Chrome tries to provide the same functionality across platforms. In this case, there are differences between desktop and mobile platforms that makes it more challenging, so I cannot really state concrete plans here. 08:24:33 igarashi: Android Chromecast application on mobile devices. Will they support Open Screen Protocol? 08:25:48 mfoltzgoogle: I can't really say. Part of the implementation is in Chrome, part is at the platform level. 08:26:15 igarashi: If the Android OS platform supports the Open Screen Protocol, it would be easy to enable it for all kinds of applications. 08:27:09 s/The Presentation API is mentioned on Edge Status/The Presentation API is not currently mentioned on Edge Status 08:27:18 mfoltzgoogle: Right, the lower level where it is supported, the more it allows to use it everywhere, I just cannot speak more concretely as it touches on various teams. 08:28:17 mfoltzgoogle: CG rechartering was done to address main feedback from the TAG around interoperability. Also in scope is extension ability for future use cases. 08:29:38 igarashi: Last TPAC, I asked whether the API would support connection to existing devices. Web application is already running on the TV, and user connects to the page running on the TV. 08:30:46 mfoltzgoogle: We have an open issue in the Open Screen Protocol when the presentation displays discovers a controller. 08:31:26 igarashi: The application may be already running on the device. 08:31:53 anssik: Let's discuss this tomorrow during the HbbTV topic. 08:32:14 mfoltzgoogle: I don't think there's anything in the protocol that prevents that, but we may need to adjust the API for that use case. 08:33:17 mfoltzgoogle: Out of scope of the CG: media codecs. Also streaming use cases (we may want to address that later on). Also network traversal, guest mode, but we should still think about it. 08:33:53 ... And finally direct interoperability with proprietary protocols (DLNA, Google Cast, etc.), but we'll still see how to enable interoperability with some of them. 08:34:45 igarashi: Audio playback is also in scope of Remote Playback API? 08:35:04 mfoltzgoogle: Yes, Remote Playback API applies to both. Things like Web Audio are out of scope for now. 08:35:20 ... Applies to HTMLMediaElement. 08:36:51 ... I don't think we've looked into remote playback when backgrounded. 08:37:52 ... I believe that, as a general rule, whatever the user agent decides to do should be reflected on the remote side. 08:40:19 https://w3c.github.io/remote-playback/#issue-container-generatedID-17 08:41:50 [discussion on what happens to media when a tab switches to background and whether we should say something about that in the Remote Playback API. For instance, for local playback, user agents typically stop rendering of the video, but not playback of audio. Probably no requirement in either direction, it should be left up to implementations] 08:42:10 anssik: Igarashi-san, please open an issue on GitHub to describe your use case. 08:42:58 mfoltzgoogle: Essentially, what we're trying to achieve is to enable second screen experiences across devices and browsers. 08:43:44 ... At a higher level, the web developer should not have to worry about internals of the discovery and of the remote device, and just be able to use it. 08:44:33 ... We're targeting a wide variety of devices and platforms, including HDMI dongles. 08:44:52 ... [going through list of functional requirements] 08:46:27 ... The channel for messages is a reliable and in-order channel, sort of TCP-like abstraction. 08:46:57 ... We want to do the same thing for the Remote Playback API but haven't looked at detailed requirements for now. 08:48:36 [discussion on Remote Playback API requirements, a polyfill of the Remote Playback API could be done on top of the Presentation API] 08:49:37 mfoltzgoogle: Also some non-functional requirements: usability, protect user privacy from other users on the network, resource efficiency. A mobile device may not have a lot of battery, memory. 08:49:56 ... Generally, goal is to keep the implementation complexity down. 08:51:20 ... The Open Screen Protocol is a stack of 4 levels: Discovery. Then Authentication to verify the identity of the discovered device. Then Transport to create a communication channel with the discovered device. And then Application Protocol to exchange messages over the transport. 08:51:47 ... I will go into details for all of these. 08:53:47 ... Among possible choices, we've done a deeper dive on mDNS and SSDP for discovery, TLS 1.3 (via QUIC) and J-PAKE for authentication, QUIC DataChannel for Transport, and we have semantics for the Application Protocol but need to focus on serialization, possibly with CBOR and Protocol Messages. 08:54:51 ... There's also some investigation on using WebSockets for Transport, in which case discovery would probably be based on DIAL, and Application Protocol would use JSON. To be discussed tomorrow. 08:56:01 ... For each of these things that we're going to dive on, we look at data we have around performance, and we collect data. We haven't done a log of data collection yet, most of the data comes from real implementation of the protocols for now. 08:57:02 ... I have a few Raspberry PIs on my desk now to investigate exactly how much network traffic is received. Raspberry devices are a good proxy for a low-end device where we might want to have the protocols run. 08:58:51 ... What we've done this far is that we listed requirements for the Presentation API, some evaluations on mDNS, SSDP/DIAL, QUIC, RTCDataChannel, more recently J-PAKE. Also some benchmarking and the control protocol. 08:59:30 ... Major items remaining: 08:59:34 ... - which discovery mechanisms to require (we have some proposal) 08:59:46 ... - QUIC DataChannel 09:00:02 ... - For the control protocol, consensus on serialization 09:00:26 ... - For authentication mechanisms, integrate J-PAKE and support PKI-based authentication 09:01:05 anssik: Thanks, that's a good summary! 09:20:59 RRSAgent, draft minutes v2 09:20:59 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html tidoust 09:22:00 scribenick: cpn_ 09:22:00 Topic: Discovery 09:22:18 btolsch has joined #webscreens 09:22:57 mfoltzgoogle: start with some background. we've looked at 2 mechanisms so far 09:23:18 ... not too much detail on DIAL, similar to SSDP 09:23:31 ... we have feedback from our Chrome implementation on how it discovers Chromecast devices 09:23:51 ... we've reimplemented all our discovery mechanisms from JS in another process to native code in the browser 09:23:57 ... this has improved reliability 09:24:49 ... the data we have now reflects the underlying protocols and not weird implementation details 09:24:55 ... shipped around Q4 last year 09:25:28 ... the key requirement is for two openscreen devices on the same network to be able to discover each other 09:25:35 Louay has joined #webscreens 09:26:04 ... this could be controllers discovering receivers, but could be the other way round, with negotiation over roles 09:26:16 ... the goal of discovery is to publish enough data to bootstrap the transport 09:26:30 ... could include a friendly name, capabilities, device model name 09:26:53 ... as the information is broadcast on the network, there's an issue of privacy 09:27:20 ... there may be other data needed as we refine the protocol stack 09:27:30 ... we want to be reponsive to when devices are added or removed, 30 second requirement 09:27:57 ... we want it to be power efficient, also as the number of devices increases we don't want huge increases in network traffic 09:28:36 ... advertising network services opens the possibility for malicious devices 09:29:10 ... mDNS has two parts to it: the multicast DNS part and the DNS service discovery, but they're mostly discussed together 09:29:34 ... there's a listener that multicasts a DNS query with a specific query type in the local domain 09:29:54 ... it sets DNS flags for this kind of query, uses a well known port 09:30:05 ... services listen for this query and return a list of DNS records that specify an instance of that service 09:30:30 ... friendly name, protocol name, e.g., for an openscreen QUIC it could be openscreen.quic 09:31:18 ... the SRV record advertises a port where the service is available, PTR record, the TXT allows additional data 09:31:31 ... when records are returned, the listener can cache them. there's a time to live 09:31:48 ... implementations are supposed to requery to refresh the cache when nearing the end of the TTL 09:32:10 ... if a device leaves the network, it can advertise records with zero TTL, which should flush caches 09:32:38 ... if a device is unplugged it may not have the opportunity to do that 09:32:49 anssik: port conflicts? 09:33:12 mfoltzgoogle: for platforms that don't provide their own listener implementation, there could be multiple running 09:33:12 Zakim has left #webscreens 09:33:28 ... if the port is opened in exclusive mode, they won't be able to send queries 09:34:08 ... SSDP is an alternative to mDNS. it's similar in some ways, different in others 09:34:26 ... UPnP. devices like routers use this to advertise services. here, we're not using it to advertise services, just for discovery 09:34:40 ... the root device advertises services, the control point wants to find services to control 09:35:06 ... when the root device comes online it advertises using headers, sent to a well known multicast port that control points can listen on 09:35:43 ... there's a UUID that the control can use to identify a device, caching information. i don't believe there's a cache invalidation part to SSDP 09:35:57 ... so you have to continually do multicast to discover that devices are no longer avaialble 09:36:11 for our purposes, we'll probably add some specific metadata for OpenScreen 09:36:21 s/for our/... for our/ 09:36:59 such as a friendly name, which would have to be base64 encoded as SSDP doesn't specify a character encoding 09:37:20 ... you can add custom headers 09:38:08 louay: you could advertise the URL of a device manifest where you put the name 09:38:12 francois: could the name be used in other contexts? 09:38:30 mfoltzgoogle: no, it's custom to our protocol 09:39:30 ... control point could send a target search request, then devices respond unicast to the control point that sent the query 09:40:01 louay: when the device sends the search request, it can specify a time window, sending a multicast message could cause replies from many devices 09:40:15 ... this may have implication on responsiveness in device discovery 09:41:16 mfoltzgoogle: for plain SSDP, devices can advertise disconnection 09:41:33 ... respond by removing the device from caches 09:41:57 ... DIAL discovery just uses the search request and response part of SDP, then request and XML document 09:42:15 ... last time we looked at it, we decided we don't need an XML document for OpenScreen 09:43:03 ... all of these things face challenges when deployed in the field 09:43:11 ... we've supported mDNS and DIAL in Chrome for some time 09:43:19 ... reimplemented to fix some issues 09:43:38 ... number one complaint is that the browser can't find their cast device or TV 09:44:17 ... on certain OSs, users can configure firewalls, Windows has settings that can block multicast 09:44:23 anssik: what do the default configurations do? 09:44:41 mfoltzgoogle: the defaults seem to work fine 09:44:58 ... but if you set up your LAN as a non-trusted network, less so 09:45:36 btolsch: the default behaviour on windows is to show a prompt on first attempt to access a multicast prompt 09:45:46 ... in Chrome we try to delay that until there's a specific user action that needs it 09:46:15 anssik: do you know the user denied access? 09:46:33 btolsch: no, we don't know. we could still probe the firewall 09:47:06 anssik: what does the prompt look like? 09:47:17 btolstch: it's not like the UAC prompt, it;s a window that opens that you can ignore 09:48:20 ... it's a strange prompt compared to others the user may be used to, so they may say no. another reason why we delay the prompt 09:48:50 anssik: you're looking at windows and Mac OS 09:50:20 mfoltzgoogle: signed software is generally allowed access, but there are settings that could block access 09:50:23 s/signed/on Mac OS, signed/ 09:50:51 mfoltzgoogle: peer to peer communication may not be allowed on a guest network 09:51:21 ... on Windows, if there are multiple appications that want to bind to the port, could prevent us binding for multicat 09:51:32 ... problematic with mDNS, which uses a fixed port 09:52:03 ... Chrome has an enterprise policy to disable all cast functionality, concerns over network traffic 09:52:15 ... they could have more restrictive firewalls blocking multicast 09:52:39 ... we don't always get enough feedback on the causes of problems 09:52:54 anssik: there's a wide range of devices with different capabilities. how can you capture say 80% of those devices? 09:53:30 mfoltzgoogle: we don't try to test against a wide variety of devices. we have to test on a case by case basis in our lab 09:54:18 ... given this context, what Chrome does to maximize chance of discovery, we advertise the same UUID through both mechanisms 09:54:31 ... if we discover one through SSDP, we don't get a port number. may not be a cast device 09:54:38 ... could be another generic DIAL device 09:54:58 ... we have data on how this performs to share 09:55:40 ... 69% is found first through mDNS, then through both mechanisms 09:55:51 ... 10% is reconnection attempts to devices previously found 09:56:16 ... 8% is mDNS only, 8% is DIAL only, 3% is DIAL first, then mDNS 09:56:32 0.32% is by looking at our network cache 09:56:39 s/0.32/... 0.32/ 09:57:23 mfoltzgoogle: on Mac, there's a bigger difference 09:57:30 ... the majority we find through both 09:58:00 btolsch: what was the data volume for Mac, does that cause the variance? 09:58:49 mfoltzgoogle: i'd have to check 09:59:01 ... for ChromeOS, we see the majority of devices can be disocvered through both 10:00:49 ... how many would you find if you find 100 by dual discovery? 10:01:14 ... in general mDNS is more likely to find a given device. 96% seems to be a ceiling, there's about 5% failure due to network issues 10:01:30 ... failure rate on Windows is 10% for both mDNS and DIAL 10:01:41 ... adding DIAL increases reliability by 5-10% 10:02:20 ... what i recommend for our implementation is to focus on mDNS as the mandatory mechanism. it's more reliable across the board, and has better platform support 10:02:25 ... eg, as it's built in on Mac 10:03:01 ... we should specify SSDP as an alternative, but not make it a core protocol 10:03:26 ... we could evaluate other mechanisms such as NFC and QR codes 10:03:33 anssik: this seems reasonable based on the data 10:03:53 ... we previously discussed dual-mode, but then decided to make a data driven decision 10:04:15 ... comments on the recommendation? 10:04:57 francois: about the data, what are the devices you tested? can you identify specific devices that are problematic? 10:05:15 s/francois/tidoust/ 10:06:10 mfoltzgoogle: the best information we have is the client platform. we don't collect a lot of detailed data 10:06:15 ... when users give us feedback, we gather additional data 10:06:33 btolsh: this data is only really for Chromecast devices 10:07:00 mfoltzgoogle: we also do TVs, but we don't have data on those 10:07:58 anssik: the recommendation prioritises mDNS 10:08:11 mfoltzgoogle: mDNS has parameters such as number of retries that can be played with 10:08:53 cpn_: One comment is that HbbTV only uses SSDP (DIAL). To be revisited when we discuss that tomorrow. 10:09:10 mfoltzgoogle: Right, this recommendation is only for the modern stack of the protocol. 10:10:41 louay: discussed with chris yesterday, HbbTV are looking to adopt existing W3C specs. we want to focus on the openscreen protocol 10:11:17 ... i think this is a good proposal to have mDNS. if HbbTV adopt OpenScreen, we still have SSDP as the alternative 10:13:01 anssik: so we can make a resolution 10:13:38 PROPOSED: make mDNS mandatory for controllers and receivers. Make SSDP a non-mandatory alternative 10:14:31 [general agreement] 10:14:36 RESOLUTION: make mDNS mandatory for controllers and receivers. Make SSDP a non-mandatory alternative 10:15:06 mfoltzgoogle: we have some open GitHub issues 10:15:37 ... related to discovery, in addition to this resolution 10:16:31 -> https://github.com/webscreens/openscreenprotocol/issues/81 #81 [SSDP] Update implementation information 10:16:55 -> https://github.com/webscreens/openscreenprotocol/pull/88 Related pull request 10:17:26 louay: i just submitted a pull request on implementations. it adds libupnp and peer-ssdp. 10:17:48 francois: any more to add? 10:17:59 anssik: that can close the issue 10:18:56 ... when mark adds the MX value 10:19:37 mfoltzgoogle: the MX is 2 10:20:43 anssik: next is the amplification attack issue 10:20:43 https://github.com/webscreens/openscreenprotocol/issues/57 10:21:05 -> https://github.com/webscreens/openscreenprotocol/issues/57 #57 - [SSDP] Update proposed use of SSDP to specifically prevent SSDP amplification attacks 10:22:06 mfoltzgoogle: some router firewalls may prevent this. i believe the correct thing to do is ensure only local IP targets 10:22:59 ... we've previously added info on security mitigations for SSDP 10:24:08 anssik: next issue: prefiltering 10:24:48 -> https://github.com/webscreens/openscreenprotocol/issues/21 #21 [SSDP] Investigate mechanisms to pre-filter devices by Presentation URL 10:24:52 mfoltzgoogle: i wanted to get feedback on how useful this would be. we haven't figured out how to apply this to mDNS yet 10:25:14 [Noting in the minutes that mfoltzgoogle self-assigned #57 and will propose some text] 10:25:14 ... we could adopt a simpler version for mDNS or omit it entirely and require all the checks to be done over the transport protocol 10:25:43 ... i see value in limiting the number of connections, to see if it improves UX and performance of the protocol 10:26:15 louay: there are two aspects. one is performance. could be faster to do discovery, but we're sharing all the URLs during discovery. privacy issue 10:27:04 ... at the app protocol level, can do caching, it keeps discovery simple, just share IP address, port, friendly name, maybe protocol version to allow for future versions 10:27:32 mfoltzgoogle: we have an open item for that, particularly for the connection establishment stage 10:28:11 -> https://www.w3.org/2001/tag/doc/APIMinimization Data Minimization in Web APIs TAG Finding 10:28:11 ... for the TXT record, i would want to have room to advertise protocol version, capabilities, public key 10:28:31 anssik: there's a TAG finding on data minimisation, also applies to protocols 10:28:49 ... we may get push-back during privacy review if we disclose too much 10:29:25 louay: also an issue, UDP packets have a limited size. what happens if we have 10 URLs? 10:29:51 mfoltzgoogle: if we want to advertise receiver URL schemes, make this a general capability advertisement 10:30:13 louay: also relates to HbbTV, want to launch HbbTV application 10:31:24 mfoltzgoogle: if they have a specific URL scheme, otherwise require the controller to ask for a specific URL when they want to determine compatibility 10:31:51 ... it's more privacy preserving, simplifies discovery. potential downside is requiring user to pair the device, e.g., J-PAKE. could be a usability reason for doing this in future 10:32:13 anssik: what are the other use cases where this could be an issue? 10:32:36 mfoltzgoogle: go to your friends house, not used befoer 10:33:03 tidoust: are only HTTPS urls supported? 10:34:31 ... in SSDP, the proposol is to have a protocols header that can be used to advertise supported URL schemes 10:34:47 ... it's a list of URL schemes other than HTTPS, so you can't advertise that you don't support HTTPS 10:35:31 mfoltzgoole: if we need to support cast only and/or hbbtv-only, we could make it a full list 10:36:01 ... this may be a moot point, as we're discussing not having that data at all 10:37:03 cpn_: Anything related to discovery of media capabilities? 10:37:08 mfoltzgoogle: Not for now. 10:38:01 cpn_: There may be a number of reasons why a presentation request may be denied. From a UX perspective, it would be better not to list discovered devices. 10:38:27 btolsch: You're asking about list of discovered devices vs. list of compatible devices. 10:38:44 cpn_: Yes 10:39:12 s/it would be better not to list discovered devices/it would be better to show the device as discovered, but not compatible/ 10:39:36 mfoltzgoogle: That's definitely a good point. In the end of the day, it's probably a UI decision for the browser. 10:40:28 ... The bigger question is, when it comes to the authentication piece, if we require a transport before we detect compatibility, that would require the user-agent to go through that process before it can show useful information to the user. 10:41:26 anssik: how to resolve this issue? 10:41:32 PROPOSED: have a protocols header that can be used to advertise supported URL schemes 10:41:55 mfoltzgoogle: i'm fine with the schemes-only header. the main issue we'd have is how it fits with data minimization 10:42:12 anssik: even the URL schemes discloses something 10:42:20 mfoltzgoogle: we could call this out in the reviews 10:43:33 anssik: is it a reasonable compromise for receivers to advertise supported URL schemes? 10:44:22 louay: the application knows how many receivers I have (not exposed to the web app) 10:45:26 mfoltzgoogle: if the receiver must advertise the schemes for the controller to make a decision, the receiver has no control over whether to advertise or not 10:45:36 ... the most conservative thing is to move scheme advertisement to the control protocol 10:47:09 PROPOSED: For SSDP, make advertisement of supported schemes truly optional, in that controllers will still connect to the receiving device in the absence of the PROTOCOLS info. 10:48:20 PROPOSED: For SSDP, make advertisement of supported schemes truly optional, in that controllers will still connect to the receiving device in the absence of the PROTOCOLS info. We'll adopt a similar mechanism for mDNS. 10:48:31 RESOLUTION: For SSDP, make advertisement of supported schemes truly optional, in that controllers will still connect to the receiving device in the absence of the PROTOCOLS info. We'll adopt a similar mechanism for mDNS. 10:49:19 RRSAgent, draft minutes v2 10:49:19 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html tidoust 10:59:33 tomoyuki has joined #webscreens 11:06:55 tomoyuki has left #webscreens 11:08:24 <_tomoyuki> _tomoyuki has joined #webscreens 11:08:52 tomoyuki has joined #webscreens 11:31:23 tidoust has joined #webscreens 11:34:28 mfoltzgooglw has joined #webscreens 11:34:43 mfoltzgoogle has joined #webscreens 11:35:34 Present+ Tomoyuki_Shimizu 11:41:51 btolsch has joined #webscreens 11:44:28 Present+ Tomoyuki_Shimizu 11:47:07 Topic: Transport 11:47:11 scribenick: tidoust 11:47:58 mfoltzgoogle: To set the background, transport is primarily about establishing network channel between 2 devices that can be used to send protocol commands (launch a new presentation), media commands and application commands 11:48:21 ... At our last F2F, we said we'd go deeper on QUIC. 11:48:50 ... I'll talk a bit about that, also about bootstrapping it. 11:49:21 Louay has joined #webscreens 11:49:25 ... We'll look at some of the challenges. E.g. ORTC API. 11:49:39 ... Then GitHub issues, proposals and next step. 11:50:29 ... Starting with an overview of QUIC: transport protocol designed primarily to allow greater parallelism between a given pair. 11:50:39 ... The QUIC ensures that one stream won't block the other. 11:50:53 cpn has joined #webscreens 11:51:06 ... You can use it for message based (fixed-length exchanges) scenarios or streaming. 11:51:18 ... The most fully specified way to do authentication is based on TLS 1.3 11:51:51 ... It also supports different congestion control. QUIC enables a different mechanism that tries to maximize the bandwith per protocol. 11:52:26 ... You can do a 0-RTT session resumption, meaning you can resume and exchange messages in the same packet. 11:52:48 igarashi: Encyrption of the payload, is it defined in the spec? 11:53:09 mfoltzgoogle: Key-exchange and encryption is defined in TLS 1.3. 11:53:40 ... In theory, you can roll out your own authentication, but I don't think there has been any other attempt than just using TLS 1.3 11:54:15 ... QUIC has a 2-layer definition. Top layer is a QUIC connection: encrypted channel between a controller and a receiver. 11:54:40 ... In principle, the spec allows multiple connections to use the same IP and port. 11:54:57 ... Every QUIC packet has a connection ID and each point uses that to distinguish the connection. 11:55:29 ... Whether port sharing is or is not in v1 seems to remain an open issue, there's a long discussion right now on GitHub. 11:55:38 ... Might be important for us. 11:56:55 igarashi: Network congestion control is separate per connection, or per port sharing set of connections. Flow control. 11:57:14 -> https://github.com/quicwg/base-drafts/issues/714 #714 [QUIC] Multiple connections on the same port 11:57:17 mfoltzgoogle: That's a good question. Believe network congestion is per port sharing set of connections. 11:58:46 ... Within a connection, the API exposed allow sending data on the stream. The receiver receives the bits in order. If there are multiple streams, the QUIC protocol will try to share the bandwith equally. 11:59:08 s/bandwith/bandwidth/ 11:59:22 ... Different ways to think about mapping our control protocol to QUI connections and there are pros and cons to each of them. Don't have a strong preference for now. 11:59:40 ... Both protocols allow multiple connections between a controller and a receiver. 12:00:13 ... We could use stream IDs to label individual messages sent between end points. But then, how do you order these commands? 12:00:44 ... Similarly, for each presentation connection, we could establish a separate QUIC connection. 12:01:09 ... Streams could be used to frame the messages between the end points and we wouldn't need a framing algorithm on top of it. 12:01:36 ... Some of the disadvantages is that each connection requires a separate crypto handshake, so additional setup time to start with. 12:02:08 ... The alternative is to use a single QUIC connection for all presentations between controlling and receiving ends. 12:02:29 ... QUIC stream for each channel command/response. 12:03:33 ... The advantage here is that we don't have to deal with different connections, but each side has to do some book keeping on streams to assign them correctly. 12:04:00 ... Some feedback from QUIC folks would be useful to decide on which of these 2 approaches is preferrable. 12:05:09 ... Congestion control: good article on blog.apnic.net. Congestion control is about figuring out the rate at which it may send packets without having to resend packets. 12:06:20 ... CUBIC and Reno have been used in the past. They ramp up until packets get lost and start again from a lower level. BBR is a new method with a different approach. Initial data suggests that it works well. 12:07:14 ... It's interesting and useful: if you have multiple devices that are streaming in your home. 12:07:57 ... We might have some data to report on that based on our tab mirroring later on. 12:08:58 ... About the handshake, the client introduces some preliminary information. Then key exchange, with certificates. 12:09:11 ... Not an expert in TLS, so you'll have to refer to the spec for details. 12:09:34 ... Part of the outcome of that handshake is a hash of approval that the handshake was successful. 12:10:03 ... If the server caches that and the client includes that hash later on, you don't have to redo another round-trip to resume a session later. 12:10:44 ... This mechanism is a bit more sensitive to replay attacks though. 12:12:11 ... QUIC DataChannel. QUIC is UDP-based. At some point last year, the WebRTC WG looked at combining QUIC with the mechanism to agree on an IP address and port between ports. 12:12:26 s/between ports/between peers/ 12:13:26 ... That mechanism is called ICE. So instead of sending UDP packets directly, ICE gets used, which typically uses a third-party server to detect configuration parameters. 12:14:42 ... I'll briefly go through ICE. Basically, through a signaling channel, ICE starts sending specific kinds of packets. Peers usually select the best pair of candidates. 12:15:41 ... STUN is a way for a network endpoint to find its public IP address, which can be used to offer an IP/port pair to the other end. 12:16:07 ... In order for this to work for a QUIC DataChannel, there are a couple of things we can do. 12:16:28 ... We could use host candidates (candidates that are directly usable) 12:16:45 ... The controller can add a host candidate that it discovers through mDNS discovery. 12:17:51 ... The host candidate for the receiver would have to be an extension of our protocol. We would have to devise some mechanism by which the receiving end can advertise a point where it can be given the host candidate from the controller. 12:18:31 s/QUIC DataChannel/QUIC DataChannel on the LAN/ 12:19:06 ... To get ICE started at all, you need to setup STUN parameter, but we don't need STUN servers. 12:19:56 ... This is something that we can and that would be compatible with what is being done in WebRTC. However, that is a bit complex for our use cases. 12:20:12 ... My perspective is that we should start without ICE, and then consider adding ICE later on. 12:21:11 ... I'm discussing with WebRTC folks to know whether we can do ICE without a signaling channel when we do not need it. 12:21:39 anssik: I note this is not yet part of the WebRTC WG. In incubation for now. 12:23:26 [Discussion about status of ORTC] 12:26:42 [Discussion about bootstrapping the QUIC DataChannel without ICE and on how ports get assigned] 12:27:07 cpn: Wondering about the scope of what we're trying to achieve here. 12:27:40 mfoltzgoogle: We don't need NAT traversal here, ICE would provide a path. But it's out of scope for now. It's more to provide a clean upgrade path to v2. 12:28:02 ... I hope to get more information about the use of ICE on local networks, but my current inclination is not to focus on that. 12:29:00 Louay: Same port could be used for multiple connections so one port may be enough 12:30:23 tidoust: I was more thinking of cases where multiple controllers try to connect to the same receiver. Different ports would be needed then, even if we multiplex connections on the same port. 12:30:47 mfoltzgoogle: Actually, QUIC allows to reuse the same port for connections with multiple endpoints. 12:31:43 mfoltzgoogle: Because DataChannel are fundamentally peer-to-peer, authentication is currently certificate based. 12:32:16 ... Each endpoint obtains or generates a certificate and then passes a fingerpring to the other party by secure signaling. 12:33:16 ... The fingerprint is passed into the data channel after ICE connects the initial state. 12:33:24 ... No direct support for J-PAKE 12:34:05 ... ORTC exposes several layers of transport that can be used for peer-to-peer communications, and enable use of QUIC. 12:34:28 ... ORTC uses ICE parameter under the hoods as explained before. 12:34:41 ... [looking at ORTC sample code] 12:34:58 s/sample code/sample code to establish a QUIC connection] 12:36:10 the proposed new WebRTC WG charter currently under AC review states: "In recognition of this interest, the Working Group intends to start work on a new set of object-oriented APIs [ORTC] for real-time communication." https://www.w3.org/2018/04/webrtc-charter.html 12:36:23 ... What's interesting here is that browsers that don't support the Presentation API could plug-in QUIC directly and use that as a supporting library to provide that support. 12:37:49 ... Also rumors that ORTC is also willing to expose mDNS. 12:38:02 ... For prototyping this might be good. 12:39:31 ... From an implementation status perspective, there is a framework implemented in Chrome called QUARTC. It supports BBR. Some crypto stuff is stubbed out for now. There's still a little bit of work to do there to support ICE. Also that work may be tight to ORTC work in Chrome. 12:40:03 ... That also explains why I propose to move forward with QUIC without ICE as a first step. 12:40:33 ... [showing proposals] 12:43:36 [Discussion on subnets. Proposal won't work across subnets. But discovery won't work either. Multicast-based discovery easily break across boundaries.] 12:44:37 mfoltzgoogle: If we want to extend the scope to net traversal, I'm not opposed to it, but it seems wise to solve the direct connection case to start with. 12:46:01 ... I think I managed to convince myself that we should not work on the ICE with host candidates mode to start with. Something like for a v1.5. 12:46:34 ... We just do want to support that in the future. 12:48:45 igarashi: Why not use ICE directly? 12:49:19 RRSAgent, draft minutes v2 12:49:19 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html anssik 12:49:29 mfoltzgoogle: I don't have a good solution on how to advertise the ports in mDNS. Happy to get additional feedback from ORTC group or others. 12:50:50 igarashi: Wondering in enterprise how user can select among a very large number of receivers? 12:51:37 mfoltzgoogle: It's potentially a problem. In general, if you have a very large network and doing multicast discovery, then that can create a large amount of network traffic. That's why many companies restrict multicast. 12:53:05 ... Entreprise policy may disable these features in Chrome, actually. 12:55:50 cpn: Specific question about QUIC. One of the things that we might want to do for HbbTV is to implement some round-trip time measurement to help with synchronization. Is there something that prevents that in QUIC? 12:57:03 mfoltzgoogle: No. I think we have something like that already. 12:57:46 tidoust: At the QUIC level? Why not just send packets over the QUIC connection to measure round trip time? 12:58:27 cpn: App-to-app communication in HbbTV. If we're considering moving the HbbTV protocols over to this set of protocols, we would want to do the same things. 12:59:14 ... Close synchronization is one of the features in HbbTV. The synchronization mechanism is based on round-trip time measurement of single UDP packets. 13:00:26 ... Wondering if the same thing could be possible with QUIC. 13:01:41 mfoltzgoogle: One of the inputs to BBR is the round-trip time. 13:01:51 cpn: OK, that sounds like something that we could investigate for HbbTV. 13:03:08 Louay: Could be done at the application layer 13:03:37 mfoltzgoogle: Right, if the use case is shared in different scenarios, then we could look at it at a lower level 13:03:42 PROPOSED: For transport, mandate QUIC DataChannel at transport, and mandate DataChannel over UDP mode (without ICE) in v1. Plan is to allow use of ICE with host candidates in v1.5. And integrate ICE + STUN / TURN for network traversal in v2. 13:05:24 [general support] 13:05:28 RESOLUTION: For transport, mandate QUIC DataChannel as transport, and mandate DataChannel over UDP mode (without ICE) in v1. Plan is to allow use of ICE with host candidates in v1.5. And integrate ICE + STUN / TURN for network traversal in v2. 13:07:57 mfoltzgoogle: [going through some work items with WebRTC] 13:08:53 ... [and with QUIC] 13:10:21 ... I'll scribe them as actions 13:10:46 scribenick: cpn 13:10:49 tidoust: is BBR mandated? 13:11:03 mfoltzgoogle: is more to make a recommendation 13:11:39 mfoltzgoogle: open issues 13:12:11 https://github.com/webscreens/openscreenprotocol/issues/84 13:12:30 mfoltzgoogle: this explains about using QUIC with ICE as well as UDP 13:12:50 ... the idea is to allow DataChannel semantics that could be migrated to a PeerConnection 13:13:01 ... there are slides there that cover this 13:13:32 RRSAgent, draft minutes v2 13:13:32 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html anssik 13:13:32 ... our proposed resolution here could be a way to close this issue 13:13:43 https://github.com/webscreens/openscreenprotocol/issues/83 13:15:28 mfoltzgoogle: this is an implementation question. until today, the only way to use the base transport is to pull in all of WebRTC 13:15:42 ... there will be a way to use QUIC DataChannel without requiring all of WebRTC 13:15:58 ... i'll follow up with the developers 13:16:28 https://github.com/webscreens/openscreenprotocol/issues/73 13:17:34 mfoltzgoogle: we already covered this in part. for an RTCDataChannel you need a way to signal messaging between two sides already established. WebRTC uses SDP 13:17:40 ... there'd have to be a bootstrapping channel together with authn for that channel 13:18:03 ... the goal of our current work is to not require this bootstrapping channel until it's required for network traversal 13:18:21 ... we can revisit in V2, when we're ready to include network traversal into the protocol stack 13:19:49 RRSAgent, draft minutes v2 13:19:49 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html anssik 13:20:10 anssik: if there are no concerns, we can label it as V2 13:20:44 https://github.com/webscreens/openscreenprotocol/issues/82 13:21:19 mfoltzgoogle: timeline for deployment of TLS 1.3 13:23:02 ... cpn: i can get information on that for us, as well as QUIC standardisation 13:25:52 RRSAgent, draft minutes v2 13:25:52 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html tidoust 13:45:04 Louay has joined #webscreens 13:46:34 topic: Authentication 13:49:48 mfoltzgoogle: we want to have an integrity of display section, so the browser can guarantee that's the intended display 13:50:02 ... important that message are routed correctly, so not redirected elsewhere 13:50:20 ... private data, URLs, ID, any application data is exchanged through confidential channels 13:51:36 ... the high level categories of threats to consider in our security evaluation are: passive network observers (on or off LAN, on the internet), active network attackers (traffic injection), side channels 13:51:44 ... timing attacks, spectre and meltdown 13:52:03 ... people looking at your display from far away. things to keep in mind 13:52:30 ... also insecure or malicious content. presentation connections are inherently cross-origin 13:53:00 ... if you want to prove the other side belongs to an origin, needs key exchange 13:53:15 .... UX for guidance to users for what content is being displayed 13:53:27 anssik: are there learnings from full-screen mode? 13:53:43 mfoltzgoogle: the Cast for EDU has a popup showing the origin 13:54:07 ... we don't always have full control over the UX on the receiver side 13:54:51 mfoltzgoogle: ISP misconfiguration, example of an ISP putting two customers on the same subnet, can see each other's cast devices 13:55:26 ... somehow they were routing multicast packets between the two 13:55:34 ... we added some protections in Chrome to prevent connections to public IPs by default 13:56:21 ... also, potential malicious software running on the presentation display or the UA itself. the platform should provide the best protection itself 13:56:38 ... devices such as STBs and dongles can change ownership or be stolen 13:56:57 ... it's worth us documenting these scenarios more thoroughly, does the work we've done so far mitigate these? 13:57:18 ... it's important to know what we're protection. what information do we consider private and should be protected? 13:57:39 ... i can start that, with contributions from others. we could get the WebAppSec group to also look at it 13:58:53 tomoyuki: i wrote a document about J-PAKE 13:59:01 ... it has two purposes. one is to authenticate both devices, the other is to exchange encryption keys 13:59:16 -> https://github.com/webscreens/openscreenprotocol/blob/gh-pages/j-pake.md J-PAKE walkthrough 13:59:18 ... J-PAKE is standardised in IETF RFC8236. there are two variants of the protocol 13:59:42 ... J-PAKE over Finite Field, J-PAKE over Elliptic Curve 13:59:53 ... elliptic curve is more popular 14:00:36 ... J-PAKE has two rounds. Both parties exchange two keypairs with a shared secret 14:01:47 ... J-PAKE includes two RTTS. there is also a three-pass variant proposed 14:02:06 ... we need to consider which variant is most suitable for the OpenScreen protocol 14:02:23 the purpose of J-PAKE is key exchange and authn 14:02:33 s/the purpose/... the purpose/ 14:03:31 ... we need an authn mechanism for the open screen protocol. J-PAKE provides a common key generation mechanism. should this be used? 14:03:50 anssik: from a UX perspective, does this spec impose any requirements on the length of the passcode to be typed by the user? 14:04:49 tomoyuki: i'm not sure of that detail. the two round passcode isn't user friendly 14:05:20 mfoltzgoogle: i need to look at other products and what length is used, and find out how they decide that 14:05:46 ... the main issue i see is brute force attacks. you want to prevent an attacker from succeeding by enumerating passcodes 14:06:03 ... you could have a delay scheme to prevent that 14:06:27 ... the other question I have is about the uniqueness requirement, also to prevent brute forcing. is that important? 14:07:14 tomoyuki: this is a general problem, not specific to the open screen protocol 14:07:35 mfoltzgoogle: could the screen have a permanent passcode? what are the security implications of these options? 14:08:44 mfoltzgoogle: also, there's an issue if you transfer ownership of the device with a permanent passcode 14:09:05 tomoyuki: incorporating J-PAKE into the open screen protocol 14:09:57 ... there are a couple of possible schemes. server-signed certificate. this doesn't look like a good idea 14:10:03 ... also TLS integration with J-PAKE 14:10:35 anssik: where is that specified, and what's the status? 14:11:30 ... can we reuse existing work, or would we need to specify it as part of open-screen protocol? 14:13:31 tomoyuki: we have two options to reuse work (open-source implementations). Mbed TLS provides an implementation based on TLS 1.2, extended to use J-PAKE authn and key generation 14:14:08 igarashi: is the first one compliant to the draft that was obsoloted? 14:15:14 tomoyuki: it's already obsoleted, but they intend to make an updated internet draft, but i haven't found it yet 14:15:28 anssik: how does spec expiry work at IETF? 14:16:03 igarahi: you have to update every 6 months to prevent it being expired. so an expired status doesn't necessarily mean it's bad 14:17:19 tomoyuki: there are some comments on the IETF mailing list. 14:17:42 ... the first is that it's based on TLS1.2, and TLS 1.3 hasn't been considered yet 14:18:33 ... the next is about the two message vs 3 or 4 message handshake 14:19:09 ... TLS 1.3 exchanges public keys in parallel with the negotiation. different between TLS 1.2 and 1.3 14:19:52 mfoltzgoogle: it seems like the way it was proposed is incompatible with cypher suite negotiation, making it difficult to deploy 14:19:59 ... unless you're in a closed system where everyone is on the same version 14:20:41 ... unless there's a way to make it compatible with normal client/server negotiation, it seems like it would be a non-starter for integration into TLS 14:21:31 anssik: many thanks, it's very useful 14:22:03 mfoltzgoogle: if we implement J-PAKE, it would have to be done at the control protocol level, not the TLS level 14:22:08 anssik: any UX implications? 14:22:57 mfoltzgoogle: it has implications on how we make a new transport connection. it's not successful until we've authenticated either through J-PAKE or other means 14:23:07 ... similar if part of TLS or not. it still requires a passcode 14:24:36 tidoust: i want to understand when the different steps happen. presentation request, discovery, then when does the J-PAKE step happen, ie, the user is prompted for the passcode? or is there another exchange first? 14:25:03 mfoltzgoogle: there are two state a device an be in: discovered but not authenticated, then discovered but not connected to. 14:25:36 ... for discovered but not authentcated, the UA offers a way to pair. this leads to the pairing code, then we move to the connected state 14:26:26 ... if it's implemented as part of TLS, presumably that would use the port advertised for QUIC, for the crypto handshake 14:26:47 ... if it's done at the application level, we'd use self signed certificates at the transport layer, then JPAKE on top of that 14:27:07 ... we need a separate step to verify that the TLS session is the one that did the handshake 14:27:37 tidoust: what about reconnection later? is a new session needed? 14:28:16 anssik: tomoyuki, any other comments? 14:29:08 tomoyuki: should we skip the verification process using the certificate? if J-PAKE is used for authentication 14:30:08 mfoltzgoogle: J-PAKE provides mutual authn. with fingerprints, the user would have to look in two different places. fingerprints are long, so they'd have to be readable. i think it's worth looking at as an option if J-PAKE is not suitable 14:32:37 s/should we skip the verification process using the certificate/if we use self-signed certificates, does that mean the verification of the certificate can be omitted/ 14:33:26 [side discussion on J-PAKE exchange over TLS] 14:34:23 scribenick: tidoust 14:34:44 mfoltzgoogle: Thanks for the presentation, Tomoyuki. On my slides, there's also a link to a blog that has some more material. 14:35:23 ... I transcribed the implementation of J-PAKE in Python 3. Each packet is around 1Kb in size. 14:35:53 ... It's very feasible doing this handshake using control messaging. 14:36:07 ... I think we covered some of the next steps for this. 14:36:19 ... We need to understand the requirements around the passcode. 14:36:39 ... Recommended UI for the user. Understand the key derivation function to use. 14:37:04 ... Assuming we're doing it at the control protocol level, we need to define J-PAKE key exchange messages. 14:37:24 ... And we need to determine whether J-PAKE can be used for recurring authentications. 14:38:11 ... For an initial connection, this suggests creating a TLS 1.3 connection with self-signed certificates, then use J-PAKE to derive a shared secret. 14:38:46 ... Then extract keying info from QUIC connection and verify with shared secret. Similar to what is done in Cast devices. 14:39:36 ... That verifies that the handshake on the QUI connection corresponds to the one that the J-PAKE handshake was done on. 14:40:20 igarashi: Does this ensure that the QUIC connection is secure? 14:40:40 mfoltzgoogle: It prevents man-in-the-middle attacks. 14:41:23 s/QUI connection/QUIC connection/ 14:42:00 ... Once the initial connection is complete, one proposal I want to develop more fully is to use that to derive new certificates to reuse in further connections. 14:43:26 ... The presentation display may generate a long lived signing certificate. Server sends public key to client. Client generates a long lived signing certificate. 14:43:46 igarashi: Your assumption is that you cannot exchange long lived signing certificate through J-PAKE? 14:44:42 mfoltzgoogle: No, we don't want to require a J-PAKE for every use, we need to use a certificate to record that we completed J-PAKE at some point and trust the device from now on. 14:45:35 ... Long-lived certificates may no longer be usable in TLS 1.3. Shorter-lived certificates can be created out of the long-lived certificates (signed by the long-lived certificate). 14:45:58 RRSAgent, draft minutes v2 14:45:58 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html anssik 14:46:18 ... [looking at certificate signature diagram] 14:47:24 ... The client certificate provides 2 important properties: it restricts the scope of devices that are allowed to receivers to ones that have successfully managed to authenticate before. 14:47:55 ... Secondly, it may provide some more improved privacy. We can create different certificates for different profiles. 14:49:16 ... There are some advantages about certificates. We can record in some metadata about the device such as the serial number, the device model. 14:49:52 ... We could think about generating new certificate for each connection, but that seems expensive. 14:50:45 ... We may want separate certificates for private browsing. Also we need a way to revoke certificates, e.g. when requirements change. 14:51:03 ... Some work to do, but it's probably necessary in the long term. 14:51:51 igarashi: I don't follow the details of the discussions, but if the short-term certificate is expired, new ones are generated, and re-authentication is not needed? 14:52:09 mfoltzgoogle: Right, as long as they are signed by long-lived certificates, then that's fine. 14:53:31 ... Some work to do for key-based steps. Full proposal on key exchange, full proposal on certificate structure & scope. Obviously, there are other efforts in IoT/WoT. 14:54:05 ... It's important to develop representative UI for both J-PAKE and PKI based auth because we want the users to understand what happens. 14:54:20 ... Internal team may provide feedback on that as well. 14:55:15 igarashi: Not familiar with J-PAKE, but passcode may be unique, right? E.g. printed on the device? 14:55:31 mfoltzgoogle: Problem with permanent passcodes is that there is no way to revoke them. 14:56:02 ... Rotating passcodes should be done at the same time as revoking certificates. 14:56:18 igarashi: The assumption is that the device has a display. What about devices without display? 14:56:50 mfoltzgoogle: For devices without displays, it will have the permanent passcode. 14:57:35 ... There will need to be trade-off. Maybe for audio devices, the security implications are slightly lower. 14:58:01 igarashi: Also thinking about IoT devices. Does not need to be visual. 14:58:33 anssik: Need to formalize these proposals into issues and documents 14:58:58 mfoltzgoogle: Right. At least, we have something to start with, the J-PAKE implication. I would be comfortable to specify the J-PAKE implementation. 14:59:28 ... We'll probably have to do an application level implementation on top of QUIC connection for now. 15:00:15 scribenick: cpn 15:00:39 tidoust: is the result of the J-PAKE influence the receiver, or only the controller? 15:01:05 mfoltzgoogle: after the J-PAKE is successful, both sides generate certificates, and they exchange the public parts 15:01:53 ... the certificates are stored. in the future, to create a new QUIC connection, the controller checks the server's public key in the TLS exchange using PKI 15:02:34 tidoust: the receiver creates a new certificate, to be used for all connections. how does it know which certificate to use for each connection 15:02:47 mfoltzgoogle: it has a single certificate to be shared with all clients 15:04:12 [side discussion on the detail of certificate generation and J-PAKE handshakes] 15:05:59 RRSAgent, draft minutes v2 15:05:59 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html anssik 15:07:21 mfoltzgoogle: an area for exploration, with hardware backed certificates, show device number as trusted information in the UI. we could eventually find a way for trusted manufacturer public keys to incorporated 15:07:51 ... another idea that could be explored is generating new certificates when changing the friendly name of the device. it's about the integrity of the information we display to the user 15:09:44 tidoust: is there a way for a controller and receiver to agree on the mechanism to use for passcode exchange (e.g, QR code, NFC, or other mechanisms)? 15:10:06 ... it could enable the receiver to choose which UI to present 15:11:01 mfoltzgoogle: we haven't talked about the UI aspects yet. as part of that process, a list of mechanisms could be proposed, triggering the device to show a QR code or whatever 15:11:30 igarashi: if the receiver browser can't read a QR code, it wouldn't be interoperable 15:11:52 mfoltzgoogle: we need a mandatory option, e.g., typing the code 15:12:50 mfoltzgoogle: to create the full branding, we'd need UX standards as well 15:13:13 mfoltzgoogle: chromecast has a guest mode with a short PIN or an audio beacon, not sure if still supported 15:14:13 igarashi: I'd like to share what we're doing in the HTTPS in the Local Network group 15:14:21 RRSAgent, draft minutes v2 15:14:21 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html tidoust 15:14:28 ... the web application is from a secure origin, connecting to a device, how do we trust the device? 15:14:46 ... we don't have a clear solution 15:15:07 ... my preferred solution uses PKI, others propose private certificates 15:15:37 ... the user grants the trust, so is the trust anchor 15:15:43 ... if the web application doesn't trust the user, the mechanism fails 15:17:31 mfoltzgoogle: if there were a web API for accessing manufacturer certificates, you could use to set up a WebRTC DataChannel 15:18:17 ... verify the fingerprint, take a look at the ORTC APIs 15:18:42 ... its up to the application to decide what certificates to accept in that scenario 15:19:53 igarashi: Presentation API assumes the device is trusted. device could be compromised or impersonated on the network 15:20:20 ... we need to verify the identity before exchanging information 15:20:48 mfoltzgoogle: we'd verify the identity information with a trusted source (model name and number) 15:21:13 ... this is a new infrastructure for public key stuff 15:21:18 ... i agree it's important to have trusted identity information 15:21:44 ... is the fingerprint permanent? 15:22:12 mfoltzgoogle: it's associated with the long lived certificate. it helps the controller identify which key exchange was done 15:22:25 igarashi: can be done offline? 15:23:03 mfoltzgoogle: it could be done on first boot, for example. as long as it doesn't change hands or identity. it may need to be regenerated from time to time, when we expect the user to have to re-pair with the device 15:23:30 igarashi: this mechanism could be address some of the issues we have, such as mixed content 15:24:25 mfoltzgoogle: the issue is shared with a lot of web APIs right now, e.g, Web Bluetooth, Web USB. could use some more scrutiny in general, scenarios where things could go wrong 15:25:35 ... the goal is to have sufficient security guarantees for exchange of private data. it's opt-in for web applications, they need to be aware. it's based on a security mechanism with different properties to the public internet 15:25:39 ... we wouldn't want to give out long term credentials, as a mitigation 15:25:51 .. that's just good web security design in general 15:25:52 RRSAgent, draft minutes v2 15:25:52 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html anssik 15:26:52 mfoltzgoogle: a compromised receiver could be a big issue. the controller might want to know about the origin of the receiver - e.g, a sony device, verifiied by a sony server 15:26:57 s/mfoltzgoogle/igarashi/ 15:27:45 mfoltzgoogle: adding encryption on top of this is another option. there's no inherent origin to origin security model here. we could think about adding it in future 15:28:19 anssik: issues to create coming out of this? 15:28:49 mfoltzgoogle: identity aspects of receiver certificates, origin to origin. this is a new workstream 15:29:24 ... the priority for brandon and myself are to complete J-PAKE, and see if we can derive a key exchange mechanism based on that 15:30:44 anssik: thank you everyone for a productive day 15:32:49 tidoust_ has joined #webscreens 15:32:56 RRSAgent, draft minutes v2 15:32:56 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html tidoust_ 15:33:18 [adjourned] 15:34:08 RRSAgent, draft minutes v2 15:34:08 I have made the request to generate https://www.w3.org/2018/05/17-webscreens-minutes.html tidoust_ 15:35:25 RRSAgent, bye 15:35:25 I see no action items