– DRAFT –
HTTPS in Local Network breakout

Tomoyuki started the session.

In this session, we want to discuss about how to deploy https in local network.

Goal: To connect various devices/browsers to local network with https.

Issues: Browsers requires secure context, but devices provide mixed content.

Let's Encrypt requires internet connectivity, so it is not applicable to local network.

How can we do for local network devices?

HTTPS in Local Network CG is focusing the issue.

The CG is discussing use cases for this several months.

Home network, automotive, IoTs are in scope.

The CG is also discussing requirements.

First, device discovery and identification.

Second, how to grant certificates.

Third, certificate validation.

We need secure, safe and easy mechanisms to use valid certificates in local network.

<Hexcles_> RRSAgent: draft minutes

Today's presentations are for raising discussion, so they are not limited the use cases or situations.

komasshu If devices have other access methods, it should be considered.

Daisuke started presentation.

A) Public CA Certificate

<Hexcles> rrsagent: make log public

B) Private CA Certificate.

C) Self signed Certificate.

Example of Public CA Certificate, PLEX's solution.

Pros: no need to extend UA implementation.

Cons: UA can't access the device when the internet is down, domain names and IP addresses are disclosed globally, Billions of TLS-capable IoTs have to registered to DNS.

Private CA Certificate case, Pros: UA can access device even if the internret is down.

Cons: This kind of certificate is not permitted by UA.

Private CA certificate example, ACME's OoB challange for TLS servers in local network.

ACME is generalized protocol for Let's Encrypt.

In this case, Private CA doesn't need device discovery because it knows the device name by OAuth authorization.

Self signed Certificate.

Pros: UA can access the device even if the internet is down.

Cons: (sorry missed).

Cons: There is no trust in the certificate, there is no way to revoke the certificate when the device is imperiled.

for A) we need some improvements on DNS.

for B) we need some strict conditions.

for C) we should eliminate this idea.

discussions about different trust levels of server certificates

? Is ACME's Out-of-Band an extended protocol?

Daisuke: Yes.

Another idea is to use QR code for OoB challange.

?: IoT devices needs this solution.

?: Is this solution only applicable to UA to machine?

Daisuke: IMO, this is not applicable to M2M.

?: Do you have discovery registry mechanism?

Smart TV is one of the case.

?: The discovery mechanism have to have trust.

Tatsuya: mDNS does not provide trust, currently no mechanism to provide trust.

?: (off-line environment).

Tatsuya: on line enviromnent is required only for Certificate issurance.

?: If WebRTC or such kind of APIs are provided, it would be work for this issue.

Tatsuya: WebSocket and/or TLS need this mechanism.

Tatsuya: We'd like to challenge local devices be part of network.

Tatsuya started presentaion.

HTTPS in localnetwork featuring STAR.

HTTPS in Local Network featuring STAR

STAR: proposal to extend ACME protocol.

<tomoyuki_> FYI: ACME STAR I-D: https://‌tools.ietf.org/‌html/‌draft-ietf-acme-star-00

Short-Term, Automatically-Renewed (STAR) Certificates.

Main use case of STAR is CDN.

An idea to use STAR in local network.

STAR client (NDC) is in local network, which can connect STAR Proxy (DNO) on the internet.

STAR Proxy would be device vendors.

The issue is the UA side.

UA should support some discovery mechanism.

A scenario is to verify CNAME and SNI matching.

Not to connect malicious IoT, use content is required.

Similar discussion was occured at Let's Encrypt community.

Example of device selection, pre-flight succession appears green on the user pop-up dialog.

?: pre-flight TLS is q regular TLS mechanism.

Tatsuya: even for M2M connection, initial confirmation is required.

?: Local DNS configuration with DANE may be useful.

Tatsuya: Public CA is important to trust local web servers.

?: In TLS1.3, SNI is encrypted.

Osamu: What is next step of this activity?

Tatsuya: facilitate more discussion in W3C.

Osamu: This discussion seems protocol definition, isn't it IETF work?

Tatsuya: collaboration between W3C and IETF is needed.

Tomoyuki: We need more help :-)

(sorry for poor scribing)