Discussion: Strategy for stable naming and service coalescing

[kvij...@mozilla.com]

I'd like to start a discussion on how to address two problems the FlyWeb implementation has to address: stable naming and service coalescing. For the purposes of this discussion, the term "name" refers to the hostname component of a URL referring to a connected FlyWeb service.

1. Stable naming

The key requirement with stable naming is that we assign the same name to the same service if we connect to it at two different points in time. This allows the usual HTTP browser machinery of cookies, caches, etc. to work properly.

2. Service coalescing.

Currently, the same service may advertise itself across multiple transports, or multiple addresses on the same transport. For example, a single service may advertise itself on both an ipv4 and ipv6 address. Down the line, FlyWeb may discover the same service across both mDNS and bluetooth and WiDi.

We need a reasonably well defined mechanism for determining when to coalesce these into one entry, instead of displaying multiple entries with the same service name.



One potential approach:

A service can register a metadata tag "flyid" that refers to a byte string, referred to as the service's fingerprint. This fingerprint is used as the service's name by the browser. If multiple discovered services have the same fingerprint, they are coalesced into the same logical service, and presented as a single discovered service.

The fingerprint is handled as follows by the browser:

1. The user instructs the browser to connect to a service with "flyid" fingerprint F.
2. The browser contacts the service and sends it a challenge string C.
3. The service returns a pair (P, S(C)), where P is the public key component of a key pair, and S(C) is the signature of C by the private key corresponding to P.
4. The browser verifies that F = Hash(P), and uses P to verify S(C).
5. If successful, the connection proceeds.

Obviously this glosses over a number of details, such as:
* what if two services have different names, but the same fingerprint?
* what prevents fake services from DoS-ing real services by using the same fingerprint (they won't be able to answer the challenge, but they can force the browser to try an arbitrary number of fake services before finding the true one).
* if a service is advertised on multiple transports/addresses, how does the browser prioritize which transport/address it connects over?

That said, the above is a rough sketch of an approach. I'm hoping it serves as a starting point for discussion.

Kannan

[Michiel de Jong]

Great points!

So apart from your goals of stable naming and service coalescence, will you also encrypt traffic at the transport layer?

I've been brainstorming about how to do TLS inside a local network, and that also requires a public key hash to be added to the "URL" of a service (the TLS signing certificate's fingerprint in my case, the flyid in your case).

I called my idea 'httpl' so far: https://github.com/michielbdejong/httpl/issues/4#issuecomment-183046063 - feedback very welcome!

Cheers,

Michiel.

_______________________________________________
dev-flyweb mailing list
dev-f...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-flyweb

[Blixa Morgan]

ThingSystem is looking into using a local CA as a way to encrypt and authenticate our network devices.  Something like that may be useful to FlyWeb as well.

--

-------------------------------------------
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

[Michiel de Jong]

On Thu, Feb 18, 2016 at 10:48 AM, Blixa Morgan <bl...@projectmakeit.com> wrote:

ThingSystem is looking into using a local CA as a way to encrypt and authenticate our network devices.  Something like that may be useful to FlyWeb as well.

Interesting! I didn't know that. A local CA could make sense within a big intranet; pre-install the root cert of the local CA onto 1000 computers in an organization's office, and then all clients will trust all the intranet services. If one service inside the intranet is not trusted, you can be sure that revoking its cert in one place will immediately cause all clients within the intranet to distrust it.

But if you have just two or three devices in an ad-hoc situation, this advantage of managing trust in one place seems small to me.

[Blixa Morgan]

Actually, we're looking at a slightly different approach to the trust paradigm.  By having each service only trust connections from clients that are signed by the same CA, and visa versa, we can make adding new entrants to the network fairly easy.   All a client or service has to do is generate a key, then send a CSR to the local CA.  If the user approves the request, it gets signed, and the device becomes a member of the trust network.  No changes to the http stack to make it happen, very easy for users to use, and scales nicely from 2 devices up.  Of course, if you only ever use 2 devices, it's a bit of work to setup for not a lot of gain, but I doubt very many users will have just 2 IoT devices.

[Michiel de Jong]

On Thu, Feb 18, 2016 at 11:35 AM, Blixa Morgan <bl...@projectmakeit.com> wrote:

Actually, we're looking at a slightly different approach to the trust paradigm.  By having each service only trust connections from clients that are signed by the same CA, and visa versa, we can make adding new entrants to the network fairly easy. 

Yes, that's definitely an advantage. A user could tell their browser to trust the root cert of the local CA, and then adding new entrants becomes a very nice UX. I like that part of it! However, afaics it would also allow these new entrants to impersonate https://mybank.com, right?

My brainstorm-idea of the 'httpl' URL schema would be trusting the cert of a device only for that one local URL, not other URLs (especially public ones). The downside of using a custom URL schema is of course that you can't connect using a standard browser, as it won't recognise your URL as something it understands.

Securely connecting to a device on a local network is an important problem to solve, and I've already been looking at TheThingSystem for inspiration on the topic - great to see you also participate on the FlyWeb list!

See also ekr's <public-key-digest>.printer.<special-TLD> proposal, linked from https://wiki.mozilla.org/FlyWeb#Security (at the end of the "Notes on FlyWeb Security" doc)

[kvij...@mozilla.com]

To be clear, the issues I'm bringing up here do not address transport layer security for local-area services. Transport encryption and service identity verification are separate, more complex issues which should be addressed in their own right.

The basic problem we're addressing here is a surrogate mechanism for stable naming, in an environment where a trusted DNS resolver is not a reasonable assumption.

This issue is a prerequisite for later implementations of transport-layer-security, since TLS on the internet builds on top of the stable naming guarantees provided by DNS. However, stable naming is an independent requirement even for non-secured connections to services.

[Michiel de Jong]

Right, but doesn't the proposed https://<fingerprint>.printer.<special-tld> scheme already solve the Stable Naming problem?

And in environments where security is not concern, http://<long-hash>.printer could maybe be used in the same way?

Just brainstorming here. :)

Cheers,

Michiel.

[kvij...@mozilla.com]

I have to admit that I didn't really do a proper read of that document. I'm taking a much closer look at it now it clearly lays out in detail the exact issues we're talking about.

I'll step back, review that document, and come back with thoughts.

Kannan