Leverage ncprop279 and caching for stream isolation

[JeremyRand]

One of the issues with using AIA and PKCS#11 for X.509 validation is that they can load 3rd-party subresources without any associated FPI. There are two different variants of this:

1. The destination domain can induce a TLSA lookup for any arbitrary .bit domain by sending a certificate chain that references the latter domain. Encaya cannot prevent this because Encaya doesn't know the destination domain (neither AIA nor PKCS#11 exposes the destination domain).
2. Even if we did know the destination domain, we wouldn't know the first-party domain (which could be different). This prevents us from isolating lookups of a given destination domain when they come from different first-party domains. Neither AIA nor PKCS#11 exposes the first-party domain either.

We intend to work around this by enforcing per-request isolation. However, this is going to be a major performance problem. Every TLS handshake is going to involve at least 3 PKCS#11 requests: a certificate object for the AIA Parent CA, a trust object for the Domain CA, and a trust object for the end-entity cert. And that assumes a bunch of optimizations we haven't made yet. This means that for connecting to a .bit domain over Tor, you need one Electrum-NMC request for the A/AAAA record, and then three more Electrum-NMC requests for the TLS handshake. This is, to put it mildly, a lot of latency.

In theory, we could lobby for AIA and PKCS#11 spec changes. But that's not realistically going to happen. So here's another idea:

1. At the time that ncprop279 services a request (for a destination domain, with a stream isolation key), it passes the Namecoin address that owns the name, as well as any TLSA and CRL data, to Encaya for caching.
2. When Encaya services a request (for a CommonName, which may or may not be the destination domain), it does not issue any requests to ncdns; it instead exclusively uses the set of address/TLSA/CRL data that was passed by ncprop279 to construct its responses.

The security properties look like this:

1. All external network traffic (e.g. Electrum-NMC lookups) is stream-isolated by ncprop279.
2. The state of the cache inside Encaya is not stream-isolated, but AFAICT it doesn't need to be: the only effect of the cache that can be observed by a website is in terms of whether a given TLS connection succeeds or fails.
3. If a malicious server includes a TLS cert chain for the wrong domain, it won't produce any network traffic, and that intermediate CA won't be accepted due to a name constraint violation.
4. If two first-party origins include a subresource on the same third-party domain, there will be two Namecoin lookups, with stream isolation applied. The cache will be updated twice, with different certs with different expiration dates and different serial numbers, but those certs will have the same behavior (they will both be unexpired and they will both be interchangeably valid as parent certs). Thus, there is no mechanism for the two first-party origins to observe each other's presence.

Which seems to be exactly what we want. And this means Encaya incurs zero network latency on Namecoin lookups, since it piggy-backs on ncprop279's Namecoin lookups. (If I replaced every atom of your body with an atom of equal physical properties, did I change anything? In this case, I think the answer is no.)

I want to ponder this a bit more before I'm confident that it's safe (peer review would be great!), but this seems like a major improvement over what we were planning to do.

[JeremyRand]

I spoke to Tor Project about this; tl;dr the proposal is fine and we can go ahead.

[JeremyRand]

Easiest way to expose this to ncdns would probably be a Unix socket, see #29 . We don't want to expose this over an unauthenticated socket since unauthorized writing to the cache would be a security risk.

[JeremyRand]

Easiest way to expose this to ncdns would probably be a Unix socket, see #29 . We don't want to expose this over an unauthenticated socket since unauthorized writing to the cache would be a security risk.

Actually I take that back; if we maintain the cache in ncdns rather than Encaya, then we can allow reading the cache via an unauthenticated socket. That seems less painful.