HTTPS Local Network CG -- 25 Oct 2018

+<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 +

+ +

HTTPS in Local Network from the aspect of W3C WoT WG

+
+...: WoT CR to be published in January
+... We still have a window for few small features, but not much space
+... Deliverables: Thing Description (JSON serialization, JSON-LD)
+...
+... (showing JSON-LD version of TD) +

+<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 +

+ +

Review and Discussion on Proposals [Presenters: Igarashi-san]

+ +

Publicly Trusted Cert. and Local Network Discovery by Tatsuya Igarashi (@igarashi50)

+ +

+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) +

+ +

Draft proposals for supporting local HTTPS without publicly trusted Certificates by Daisuke Ajitomi

+ +

+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 +

+ +

Wrap-up

+ +

+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 +

+ + +

- DRAFT -

HTTPS Local Network CG

25 Oct 2018

Attendees

Contents

HTTPS in Local Network from the aspect of W3C WoT WG

Review and Discussion on Proposals [Presenters: Igarashi-san]

Publicly Trusted Cert. and Local Network Discovery by Tatsuya Igarashi (@igarashi50)

Draft proposals for supporting local HTTPS without publicly trusted Certificates by Daisuke Ajitomi

Wrap-up

Summary of Action Items

Summary of Resolutions