<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