W3C home > Mailing lists > Public > public-html-media@w3.org > October 2015

Re: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

From: Bob Lund <B.Lund@CableLabs.com>
Date: Wed, 21 Oct 2015 20:58:52 +0000
To: Mark Watson <watsonm@netflix.com>
CC: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <D24D4550.569FA%b.lund@cablelabs.com>
Mark and All,

The home network HTTPS solution we came up with makes TLS authentication work in the usual fashion between a commercial browser and a home network web server. The home network web server is assigned an FQDN so that a CA certificate can be issued. A TLS server certificate, trusted by the browser, is assigned to the home network web server. DNS is configured to resolve the FQDN to the IP address eventually assigned to that home network server device.

Here is an example illustrating the details:

  1.  A unique FQDN is assigned to the home network web server at manufacture time, e.g. macAddress.sp.com.
  2.  A DNS entry is generated with that FQDN. This entry could be in a cloud DNS server, a home DNS server or the home router that does DNS intercept.
  3.  A signed certificate is generated for that FQDN and installed in the home web server at manufacture time.
  4.  When the home network web server device is assigned an IP address, the DNS entry created in step 2 is updated with the assigned IP address using a, at this point, proprietary protocol.
  5.  The FQDN is used in links on the web page that accesses the home network web server resources. When the browser fetches content from macAddress.sp.com, DNS resolves the FQDN to the home network web server IP address.
  6.  The home network web server returns a certificate , signed by a trusted CA, with the common name of macAddress.sp.com

This solution relies on steps that may not be possible in the general case:

  1.  The home web server can be assigned an FQDN.
  2.  Web page creation, or a discovery process, provides the home web server FQDN for use in appropriate links.
  3.  The DNS entry can be updated when the home web server is assigned an IP address.
  4.  DNS resolution of the FQDN to the home web server IP address can be done by, or on the path to, DNS used by the browser accessing the home web server.

Bob


From: Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>>
Date: Thursday, August 13, 2015 at 10:14 AM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>>, "<public-html-media@w3. org>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: Re: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

Bob,

Could you elaborate on the potential solutions ? We have the same issue in the Second Screen working group, for direct LAN communication between browser and second screen devices.

...Mark

On Thu, Aug 13, 2015 at 9:08 AM, Bob Lund <B.Lund@cablelabs.com<mailto:B.Lund@cablelabs.com>> wrote:
Paul and all,

This issue was created to engage the Web App Sec WG on the practical problem with HTTPS as the sole mechanism for establishing a privileged context in LANs, i.e.  how would one deploy millions of TLS server certificates in home network web server devices that would be trusted by commercial browsers, without user configuration.

We've been having discussions about potential solutions with a certificate authority and a home network device supplier. It appears that there are solutions that might work with existing browsers, DNS, home network devices and CA certificate processes. So at this point, there are no issues to raise with the Web App Security WG. It probably makes sense to close this issue at this time.

Bob

From: Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>>
Date: Thursday, August 6, 2015 at 8:19 AM

To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: "<public-html-media@w3. org>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: RE: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

> Once that is completed, we'll know what action to take with WebAppSec.

Can you give us an update on ACTION-93 before the Aug 18 Media TF meeting when we will discuss EME topics?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596<tel:%28425%29%20705-9596> Fax: (425) 936-7329<tel:%28425%29%20936-7329>

From: Bob Lund [mailto:B.Lund@CableLabs.com]
Sent: Monday, July 06, 2015 4:25 PM
To: Paul Cotton
Cc: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: Re: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."



From: Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>>
Date: Monday, July 6, 2015 at 12:56 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: "<public-html-media@w3. org<mailto:public-html-media@w3.%20org>>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: RE: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

Is there any change in the status of ACTION-93?

Some progress is being made. The essence of the problem is that HTTPS to home network web servers requires a sever HTTPS certificate that is in the client browser's trust store. Upcoming CAB Forum requirements will limit these types of certificates to hosts with FQDNs, which is not something home network hosts typically have. We are in the process of working with a CA to understand options and what impact, if any, these might have on browser requirements. Once that is completed, we'll know what action to take with WebAppSec.

Bob

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596<tel:%28425%29%20705-9596> Fax: (425) 936-7329<tel:%28425%29%20936-7329>

From: Bob Lund [mailto:B.Lund@CableLabs.com]
Sent: Monday, June 15, 2015 5:12 PM
To: Paul Cotton
Cc: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: Re: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

Paul,

We're still assessing the specific issues regarding problems with HTTPS with home network devices. I don't have an update as to when we'll come to conclusions and submit a bug with the WebAppSec WG.

Bob

From: Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>>
Date: Wednesday, June 10, 2015 at 10:00 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: "<public-html-media@w3. org<mailto:public-html-media@w3.%20org>>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: RE: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

You previously responded on Jun 1 that your were doing some private work on this matter before contacting the WebAppSec WG.  Can you give us any update?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596<tel:%28425%29%20705-9596> Fax: (425) 936-7329<tel:%28425%29%20936-7329>

From: Paul Cotton [mailto:Paul.Cotton@microsoft.com]
Sent: Monday, June 01, 2015 5:03 PM
To: Bob Lund
Cc: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."

ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."
http://www.w3.org/html/wg/media/track/actions/93

Can you provide an update on this action item from the May 19 TF meeting [1]?

/paulc

[1] http://www.w3.org/2015/05/19-html-media-minutes.html#item06

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596<tel:%28425%29%20705-9596> Fax: (425) 936-7329<tel:%28425%29%20936-7329>
Received on Wednesday, 21 October 2015 20:59:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:06 UTC