Thoughts on TOFU

[colecmac at protonmail.com]

> I would love to! And I have loads of ideas on this front.

Happy to hear it! Let's do this :)

> I do think that "controlling how servers use certs" is [a good idea]

This is probably the only way forward, but unfortunately it complicates things.
It makes Gemini less simple, because people can't stick to what they
know about certs, or just use the existing one they have for their domain.
I guess we just have to try and get servers to support this and abstract it
away.

> -   Servers can sign their new cert with their previous private key.
>     Then TOFU clients which accepted the previous cert can validate the
>     changeover - and then immediately stop trusting the previous cert so
>     that anybody who stole the private key can't sign their own new cert.
>     Basically, when you accept a new cert you also grant it one-use-only,
>     very-limited-scope CA powers.

BLoCkcHaiN style, nice ;)
This does mean that servers would have to serve up an ever growing certificate
chain though? I think? Because otherwise how can a client verify that it was signed.

I guess the servers only need to serve up two certs, the previous and current, but
if I boot up my client after a year, then how does it know whether it just has missed
some certs in between, or if there's an MITM attack?

> -   Servers can generate their new self-signed cert N months in advance
>     and, for those N months, advertise the hash of the new cert at a
>     well-known endpoint, access to which is secured by the current cert.
>     TOFU clients can notice when an accepted cert is close to expiry and
>     pre-fetch the future fingerprint.

The problem is still like what if I miss a cert? Like if my client got cert 1 and
the hash of cert 2, but by the time I come back online, that site is serving cert 3
and I don't know whether that's one I should trust or not.

> -   Servers can use DANE (RFC6698) to advertise their self-signed cert
>     over DNS, and TOFU clients can check this when receiving an unrecognised
>     cert. LOTS of details to discuss here re: DNS security.

DANE seems cool, I want to look into it more. But it will complicate things, and then
there's DNSSEC, etc etc. I'm guessing it should be avoided for now.

> -   We could built Perspectives/Convergence style "notary" servers that
>     TOFU clients clients can consult when receiving an unrecognised cert.
>     This was an idea that was developed before it's time, IMHO. Today there
>     is no reason that achieving broad network perspective requires trusted
>     third parties and an effective "shadow infrastructure" alongside CAs.
>     Just run your own certificate observatory on a dirt cheap VPS. Share it
>     with friends, who share theirs with you. Pubnixes can run then for
>     their users. Unlike some of the other ideas, this works just as nicely
>     with CA-signed certs (like those from Let's Encrypt) as self-signed
>     certs.

This seems cool, and I want to learn more. How is conflict resolution handled?
Doesn't this need bootstrapping? It could be a good solution, but still will
complicate the protocol a lot.


I feel somewhat unsure about the problems I raised here btw, please correct me if
I've made any mistakes.

makeworld

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, June 15, 2020 3:32 AM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Sun, Jun 14, 2020 at 11:09:05PM +0000, colecmac at protonmail.com wrote:
>
> > Solderpunk, I'd appreciate if we could work towards some general solution for this,
> > and official recommendations for how to handle TOFU and cert renewal.
>
> I wouldlove to! And I have loads of ideas on this front. I've just
> never had the time to write anything substantial on them because there
> is always some more urgent matter popping up, like surprise auto-cookies
> or people wanting to add upload capabilities. If things ever settle
> down (tonight I will make official the spec changes I recently asked for
> feedback on and then freeze the thing again, perhaps that will help) we
> can tackle this.
>
> > I'm not sure what to do about this. Both options seem bad, and both will cause
> > breakage. It seems that there is no good way to do TOFU with certs, unless
> > you want to try and control how servers use certs, like specifying that keypairs
> > should not change or something.
>
> I don't think that keeping the same keypair forever is a good idea, but
> I do think that "controlling how servers use certs" is. Without CAs
> in the picture it's trivial to automate cert changes, which makes this
> easy. I also think that pushing Gemini servers to use the smallest
> certs they can (i.e. not RSA) is a good idea to reduce TLS overhead,
> which is another reason for people to take control of their own
> certificate generation.
>
> Quick sketches:
>
> -   Servers can sign their new cert with their previous private key.
>     Then TOFU clients which accepted the previous cert can validate the
>     changeover - and then immediately stop trusting the previous cert so
>     that anybody who stole the private key can't sign their own new cert.
>     Basically, when you accept a new cert you also grant it one-use-only,
>     very-limited-scope CA powers.
>
> -   Servers can generate their new self-signed cert N months in advance
>     and, for those N months, advertise the hash of the new cert at a
>     well-known endpoint, access to which is secured by the current cert.
>     TOFU clients can notice when an accepted cert is close to expiry and
>     pre-fetch the future fingerprint.
>
> -   Servers can use DANE (RFC6698) to advertise their self-signed cert
>     over DNS, and TOFU clients can check this when receiving an unrecognised
>     cert. LOTS of details to discuss here re: DNS security.
>
> -   We could built Perspectives/Convergence style "notary" servers that
>     TOFU clients clients can consult when receiving an unrecognised cert.
>     This was an idea that was developed before it's time, IMHO. Today there
>     is no reason that achieving broad network perspective requires trusted
>     third parties and an effective "shadow infrastructure" alongside CAs.
>     Just run your own certificate observatory on a dirt cheap VPS. Share it
>     with friends, who share theirs with you. Pubnixes can run then for
>     their users. Unlike some of the other ideas, this works just as nicely
>     with CA-signed certs (like those from Let's Encrypt) as self-signed
>     certs.
>
>     Cheers,
>     Solderpunk
>