+
+<urata> https://github.com/httpslocal/group/wiki/Meeting2018Oct25TPAC#agenda +
+ ++<McCool> https://github.com/w3c/wot/blob/master/PRESENTATIONS/wot-https-local-10-2018.pptx +
+ ++Presentation material (will repost in GitHub repository later): https://s01.ninja/files/1025_httpslocal.pdf +
+ ++<urata> starting meeting by Igarashi-san who is chair +
+ ++<urata> Ajitomi-san is one of presenter +
+ ++<urata> introduction +
+ ++<urata> Mizushima-san +
+ ++<urata> Maccool san from Intel@tokyo +
+ ++<urata> Igarashi, Aitomi, Sakakibara, Kajiwara, Kim, Hirano +
+ ++<urata> Horiushi, Minami, Yamada, Honma +
+ ++<urata> Explaining Agenda +
+ ++<urata> Present by Kajiwara-san +
+ ++<urata> https://s01.ninja/files/1025_httpslocal.pdf +
+ ++<urata> Why we need https-local? +
+ ++<urata> Browser requires https for various powerful features +
+ ++<urata> installing self singed root CA is not good solution +
+ ++<urata> Introduce Github repo (refer slide) +
+ ++<urata> Scenario Overview +
+ ++<urata> 1. direct access from UA +
+ ++<urata> 2. Machine to Machine +
+ ++<urata> 3. Cross Origin +
+ ++<urata> Home NAS device example +
+ ++<urata> UC-07: Secure offline communication for Home Automation +
+ ++<urata> https://github.com/httpslocal/usecases +
+ ++<urata> use case description +
+ ++<urata> Scenario: PublicCA Cert for devices accessible globally +
+ ++<urata> e.g. Mozilla's Things Gateway +
+ ++<urata> Pros, Cons explained (refer slide) +
+ ++<urata> Scenario: Public CA Cer for devices accessible only in the local network +
+ ++<urata> Scenario: Private CA Cert +
+ ++<urata> Scenario: Self-Signed Certificate +
+ ++<urata> Move on: Missing use case? Scope too large? +
+ ++<urata> Questions? +
+ ++<urata> McCool: use cases such as network camera +
+ ++<urata> .. lot of iot devices deployed +
+ ++<McCool> https://github.com/w3c/wot/blob/master/PRESENTATIONS/wot-https-local-10-2018.pptx +
+ ++<scribe> scribenick: ryo-k +
+ ++mmc: Presenting the current state of Web of Things standardization and strawman proposal for httpslocal +
+ +
+<urata> ...: slide page 4
+...: Use case of httpslocal - Have a directory of local device, and have it deliver TDs securely
+
+igarashi: q. security scheme standardized? +
+ ++mmc: there are 8 of them +
+ ++<urata> ...: s +
+ ++<urata> ...: slide page 5 +
+ +
+<urata> ...: slide page 6
+...: security schemes are overridable in a nested object
+... security schemes : oauth2, psk, digest...
+... (strawman)
+
+<urata> ...: slide page 8
+...: there are standardized work in CoAPS specification. psk, cert, public
+... one option here: what if we used these with HTTPS?
+
+CoAP spec: https://tools.ietf.org/html/rfc7252 +
+ +
+mmc: Public key is like using a local CA.
+...: "psk": key pre-distribution is needed
+
+igarashi: We need a scheme that works under un-managed networks +
+ ++mmc: Do our current set of parameters support the use cases? +
+ ++igarashi: We have already discussed pre-shared key based protocols such as J-PAKE +
+ ++mmc: This is more for machine-to-machine than for browsers +
+ ++igarashi: psk/dtls/coaps equivalently secure as tls1.3? +
+ +
+mmc: dtls should be equivalently secure
+...: Next thing on rechartered WG is to have a discovery service
+
+igarashi: browser vendor support for coaps? +
+ ++mmc: actually mozilla just took out coaps. they might be going for their gateway product. google chrome does not support +
+ ++kouhei: does psk with https mean extending TLS? +
+ +
+mmc: psk works under coap
+...: it's where the key comes from
+
+ryo-k: does that result in modifying all the tls libraries in the wild? +
+ ++mmc: maybe the configuration files. currently this is a strawman proposal to take the definition of coaps and adapt it to https +
+ +
+igarashi: Background. We had breakout sessions / discussions throughout 5 years of TPAC
+...: Some solutions for using publicly trusted certificates on local servers e.g. PLEX
+
+<urata> https://github.com/httpslocal/group/blob/master/20181025_F2F_TPAC2018/PubliclyTrustedCert_and_LocalNetworkDiscovery_W3C_TPAC2018.pdf
+...: We may use Let's Encrypt to get publicly trusted certs
+... Talks on Local Network Discovery under W3C. Web and TV IG, DAS WG, Second Screen CG
+... Why publicly trusted certs? (1) Not easy for consumers to install private cert
+... also very risky to install private certs onto their devices
+... Messy for users to manage security of many devices from different vendors.
+... (3) costly for small companies to manage private PKI.
+... Issues
+... (1) scalability/privacy of public dns/CT servers
+... (2) name binding issues
+
+<urata> binding public domain and local network is the issue
+...: in case of PLEX, the server should know the URL of devices in a secure manner
+... using mDNS in public DNS works only for managed networks
+
+kouhei: what is the threat model for privacy issues when using PLEX? +
+ +
+igarashi: The domain name might include personal information eg. owner name, and if these are disclosed through CT logs, they are now in the public
+...: PLEX means assigning global names to private IP address
+... They can know about your private IP address
+
+<urata> sakakibara: DNS has lot of privacy information is issue? +
+ ++kouhei: what's the point on personalizing domain names? +
+ ++igarashi: You need a human-readable name so that users can distinguish between devices +
+ ++hirano: the names should be unique, (how to handle uniqueness?) +
+ ++igarashi: please look at the URL for details +
+ ++<urata> PLEX solution: https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/ +
+ ++hirano: PLEX solution proposed by browser vendor? +
+ ++igarashi: No, we asked them about how they think. There is a scalability problem with CT servers +
+ ++<urata> igarashi: PLEX solution has discovery issue +
+ ++<urata> igarashi: introduce candidate solutions +
+ +
+igarashi: Solution proposal. About scalability issue, short-term STAR certificates may work, because they don't need to be registered to CT logs
+...: alternatively, using Technically Constrained Subordinate CA Certificate defined by CABF Baseline guideline
+... Not supported by all major browsers yet
+
+<urata> ajitomi: this solution is for intranet? +
+ +
+<urata> igarashi: no, not limited to that
+...: about binding issue, extension to local network discovery can address the issue
+
+<urata> igarashi: (propose strawman idea figure)
+...: W3C is a good place for this discussion, because secure contexts/mixed content is discussed under Web Security Standards under W3C
+... (slide of proposal @ TPAC2017)
+
+ajitomi: Proposals NOT based on genuine Web PKI certificates +
+ +
+<urata> https://github.com/httpslocal/group/blob/master/20181025_F2F_TPAC2018/20181025.w3c-tpac.httpslocal.proposal.pdf
+...: HTTPS for Local Domains by Martin Thomson @ Mozilla
+... Issues for Web PKI-based solutions. (1) The device vendor should be responsible for guaranteeing the authenticity of the device, not the user
+
+igarashi: there should be a different guideline for local devices. local devices need necessarily not comply to webtrust +
+ +
+ajitomi: (2) Readability/memorability of domain names
+...: .local indicate that they are local network devices
+
+<urata> Martin's proposal: https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit
+...: Martin's proposal
+... challenge for local domains - names are not unique
+... solution - extending the origin makes this possible
+... web origin consists of scheme host port
+
+<urata> ...: proposed solution "extending origin"
+...: adding additional property to that tuple guarantees uniqueness
+
+<urata> ...: (showing UI figure in page 6) +
+ ++<urata> igarashi: if there is lot of printers in a room, this can be an issue +
+ ++igarashi: some kind of discovery api would be necessary if there are multiple devices of same vendor exists +
+ ++hirano: maybe discovery api out of scope for https in local domains? +
+ ++igarashi: the proposal does not talk about uniqueness of local domains. +
+ ++kouhei: it addresses the uniqueness of local domains by extending the "origin" by adding SPKI hash +
+ ++ajitomi: (shows the URL with SPKI hash, talks about TBD details) +
+ +
+<urata> martin proposed URL example: https://_NPNE4IG2GJ4VAL4DCHL64YSM5BII4A2X.printer.local
+...: Has drawbacks, like key changes, address changes, ...
+
+@2: How does the browser find out which IP address "printer.local" ? +
+ ++igarashi: they may be discovered through mDNS +
+ ++hirano: communication encrypted? +
+ +
+ajitomi: the way to install private CA on the browser is not mentioned
+... Ajitomi-san's proposal
+
+<urata> Ajitomi-san's proposal: https://github.com/dajiaji/proposals/blob/abstract_proposal/draft_proposal_supporting_local_https_communication.md
+...: Two access patterns, normal access and cross-origin access pattern
+
+(btw, the m2m case and direct access case in my slide corresponds to the "normal access case" in his slides
+...: 3 candidate solutions. PAKE-based approach, OAuth/ACE based approach, Device vendor issued certificate
+... 1. User's approval, 2. webauthn-like trust model (app layer solution), 3. trust model (tls-layer solution)
+... 1. Use PAKE based on user's approval
+... Add type: "pake" parameter to fetch API. In this case, a confirmation UI is shown
+... before 2 and 3, describe WebAuthn's trust model
+... There is a trust relation between FIDO server and Authenticator / RP and FIDO server
+... This trust model can be matched
+... approach 2: calls fetch API with rpk + raw public key or fingerprint / pkix + SPKI based fingerprint
+
+<urata> ...: +
+ ++igarashi: In the WebAuthn case the authenticator device is guaranteed to be secured, but we cannot assume that local device is secured in this case +
+ +
+ajitomi: (approach 3) use private CA certs based on device attestation and user approval
+...: needs same kind of extension to fetch API
+... browser regards this value (spki fingerprint) as a temporary trust anchor
+
+horiuchi: in this case, authorization server needs to know that resource server is in local network. how does it do so? +
+ ++ajitomi: addressed in last TPAC, please check slide +
+ ++igarashi: one of the big issue is that we need to distinguish between managed and unmanaged network +
+ +
+<urata> igarashi: Martin's idea is for managed network
+...: we mostly worked on unmanaged network
+
+kouhei: think the use cases are sufficient, but what are the technical constraints? +
+ ++igarashi: next steps: we need to clear the scope. continue discussion on GitHub / follow-up F2F meeting +
+ + +