Extended origins for non-unique names

[martinthomson]

Something to consider.

https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit?usp=sharing

It requires a change to browser policy about names, and has some interactions with UX.

[dajiaji]

@martinthomson Many thanks for your proposal.
I'm not sure that I understood the proposal correctly, it is very interesting to me.
I have some comments and questions below.

For this, HTTP Alternative Services can be used to provide an alternative route to the device that does not depend on the external server.

It's interesting. I've never thought about such kind of solution before.

Extended Origins for Local Domains

In the main proposal, do you assume that devices that have *.local (or *.home.arpa) domain names use self-signed certificates (or RPKs)?
If it is true, I think the threat of MITM attack still remains. Is that right?

ACME Gateway for Development

Is the idea available only for development?
In other words, is there any possibility for browsers to provide local devices with ACME-server functionality (not only over loopback I/F, but also over wlan0, etc.).
Of course, there are many things to care about but I'd like to know your opinion whether it is feasible or not.

[martinthomson]

do you assume that devices [...] use self-signed certificates [...] ?

Yes. There is no name for a CA to attest to, so that's the only real alternative. You could maybe use bare public keys, I guess.

the threat of MITM attack still remains. Is that right?

If the name is not unique, then the notion of MitM is meaningless. Anyone can rightfully claim that name.

is there any possibility for browsers to provide local devices with ACME-server functionality [?]

The shortcomings of that approach are fairly severe, as the document explains. This is effectively giving write access to the browser trust store, so extending to things on the local network is basically no-go. Even with the constraints we have, it might make sense to include more safeguards like explicit authorization for requests.

[igarashi50]

@martinthomson your proposal of "extended origin for local domain" is interesting.

The proposal seems to work well in the case that there is no rogue device in the home network. But there is a concern of the "secure-origin". One of the issues is how a user can trust a non-owned device in public local network such as office and hotel. I am a proponent of using a genuine Web PKI certificate for local server as my idea. Does it make sense that FireFox shows "green padlock" as like below if a device has a genuine Web PKI certificate?

[martinthomson]

These names cannot have unique names, so it should be impossible get a valid Web PKI certificate for that name.

[igarashi50]

I may misunderstand the proposal. I thought that it is possible for a device to use any unique global DNS name for its server cert. because a browser can verify that the "extended origin for local domain" matches with the server cert. by checking the hash of SPKI(server public key information). Am I wrong ?

[martinthomson]

Either a name is globally unique or not. We already have a solution for those that are globally unique: Web PKI. This proposal only addresses those that are not unique, specifically because you cannot get a Web PKI certificate for a non-unique name.

[tomoyukilabs]

I highly appreciate these suggestions. I agree that we cannot rely on Web PKI in the case of local network devices, as long as the device name is not globally unique.

For example, this might use the underscore convention to add the SPKI hash to the domain name, https://_NPNE4IG2GJ4VAL4DCHL64YSM5BII4A2X.printer.local, or it could use a separator of some sort to partition off space for a key.

Or, could we indicate such a hash in HTTP request headers? I wonder whether the hash should be included in the device's URL or not.

[martinthomson]

Or, could we indicate such a hash in HTTP request headers? I wonder whether the hash should be included in the device's URL or not.

The point here was to ensure that these devices were hard to target with APIs like postMessage, which use a serialized origin as an identifier. It's not sufficient to modify HTTP requests for that.

I hadn't really considered the effect on CORS requests originating from the device. For that, I think that including the extended origin in the Origin header field would be enough as well. That reveals the name of the device to the server, allowing it to communicate with it (using postMessage for instance). That seems like a nice property to have, though I'd want to spend a little time on analysis there to make sure that there aren't unexpected problems.

[X-Ryl669]

To follow subresource-integrity (SRI) convention, the hash should have the algorithm used in prefix like sha256-yourhashhere so it can be updated in the future.
I would add to your proposal some sort of discovery of a .local name.
There might be multiple device answering the same name so you need a mechanism to target them.
You could require that the device register both printer.local and _sha256-spkihash.printer.local on the MDNS server, and that the webserver requesting for the former host (over HTTP and HTTPS) relocate to the second via HTTPS upgrade. Also, you can expect the device to present a unique fingerprint in its certificate that's signed with its private key, that the browser must remember as well.

For example, this could be the described process :

1. User enter printer.local
2. The browser checks if it already have a HSPKI for that name, and forward to it _sha256-prevhash.printer.local. This is to ensure that a user with 2 printers will first talk to the last one he used.
3. If no device answers to that address, the browser resolves printer.local and follow the classic redirection: http://printer.local=> https://_sha256-newhash.printer.local
   3.a. If there is more than a device answering to that address, the browser should allow the user to choose. It's a good idea then to use the content of the certificate, like the manufacturer name and model and serial number to show a list.
   3.b Or- refuse this case, and connect to the last one that broadcasted its name.

Asking for the device to remember its certificate across reset is, IMHO, a minimum requirement.
Also, a device might present a new certificate because the old one expired, in that case, if the fingerprint is still valid with the previous one, then the browser would not have to ask the user again. This means that the device's keypair is kept while the certificate expiry dates are updated, which is, IMHO a minor security loss for usability.

[martinthomson]

DNS-SD and .local work based on rules that prevent name collisions on the same network. I suppose that you could have name collisions where a device is connected to multiple networks, which is akin to the problem we see with split-horizon DNS and DoH. That is, example.com might be available and local at one address within an enterprise network, but also available on the wider internet. I don't think that it is a case that is common enough to warrant doing anything about specifically, where there are name collisions, there are problems.

[X-Ryl669]

I was thinking about computer with multiple (live) connection (like in a company where you're connected via Wifi to a very limited guest network with internet access, and via the LAN to the company's intranet). Then each connection might have their own .local entities, and globally conflicting names.

I agree that it might be much simpler to ignore this (take the 3.b route) and let the user sort this out (by disconnecting the other connection for example) when she needs to connect to the printer. After the connection is done, the browser will remember it next time even if both LAN are connected, so that's ok.