Thoughts on TOFU

Thanks for the well written response! Worth the wait :)

I see now that I have over-analyzed TOFU, thanks for pointing that
out. I think having a mostly secure protocol that works without
a centralized system is a good place to be in, even though reaching
"full" security might be mostly unattainable.

With that in mind, let me look back at those ideas again.

> * 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.

This is the one I like the most I think, it seems the simplest. Even simpler
than the signing method, because server don't need to serve multiple certs
and increase the overhead, and clients don't even need to do key validation.

Whether this is specced (as an optional client behaviour) or not, I think
the spirit of "mostly secure" suggests that at the very least, simple clients
should look at cert hash and expiry, and not just the cert public key as Felix
suggested in this thread originally. I think it'd be nice to see this suggestion
in the Best Practices file, if you agree.

Thanks,
makeworld

??????? Original Message ???????
On Friday, June 19, 2020 1:29 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Sorry for letting this thread sit for a while!
>
> On Mon, Jun 15, 2020 at 06:53:49PM +0000, colecmac at protonmail.com wrote:
>
> > > 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.
>
> Well, "different" and "less simple" aren't always the same. The
> automated cron-based approach of Let's Encrypt is very different to
> what people were used to before it came along, but uptake was swift -
> okay, in part because it was free, but also in part because it was
> actually easier. I think that anything which can be implemented as a
> cron job is feasible for widespread adoption. A cron job which does not
> communicate with any external machines is arguably even simpler than one
> which does.
>
> > > -   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 hadn't imagined an ever-growing chain, that would soon add up to some
> pretty hefty overhead. I imagined just two or maybe three at most.
>
> > 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?
>
> It wouldn't!
>
> Let me be clear: TOFU is a very simple security model. It's totally
> decentralised, totally decommercialised, involves no third parties
> beyond the server and client and you can deploy it even on weirdo
> off-grid wifi meshnets that have no connection to the Real Internet
> whatsoever. It should go without saying that something like this is not
> going to give you 100% unconditional authentication of remote
> identities under all circumstances.
>
> That doesn't mean it's rubbish. The CA model doesn't give you 100%
> unconditional authentication either (and it certainly don't look simple
> once you add in things like OCSP and CT to try and get it closer to that
> goal). In terms of the its ability to protect everyday people from
> their greatest realistic privacy threats (things like passive, automated
> bulk surveillance by their ISP) compared to its implementation
> complexity, I think TOFU can be very worth using. But you do need to
> have realistic expectations: really strengthening it up to the point
> where it can address active, targetted attacks will necessarily involve
> adding more complexity, and this is the spirit in which I brought up all
> the ideas in this thread.
>
> The role of TOFU-based TLS in Gemini is not to offer something
> equivalent to TLS on the web, so we can all comfortably send around our
> credit card numbers and make bank transfers in Geminispace even though
> criminals are actively trying to intercept us. It's to fix the glaring
> defect of Gopher whereby nobody would blame you for being reluctant to
> use Gopher to consume:
>
> -   serious political activism
> -   information about a locally-banned religion
> -   erotic literature
> -   health advice for stigmatised conditions
> -   counselling resources for abuse victims
>
>     because it would be trivial for your ISP to sell that information to
>     marketing agencies or report you to people who will haul you off to the
>     gulag (because if they don't, they're at risk of getting hauled off).
>     Or because if you're using the open wifi network at a cafe or a public
>     library or an airport, all the other patrons on that network will be
>     able to see what you're reading. I believe that people who want/need
>     to read the above should be able to read the above with some degree
>     of protection, and Gopher lets them down on that point. I honestly
>     think this keeps a lot of people who are fed up with all the web's
>     problems from migrating into Gopherspace. At the same time, I believe
>     that fixing this shouldn't require complicated and expensive
>     private infrastructure: Yes, Let's Encrypt is free for the end user
>     and I'm a big fan, but it costs millions of dollars each year to run
>     it, most of which comes from corporate sponsors and, ironically, some
>     of their biggest sponsors are companies like Google and Facebook
>     that make the money they donate by doing things that aren't good for
>     privacy!
>
>     From this perspective, TOFU provides "good enough" security at a "cheap
>     enough" price that I feel like it should be treated as a first class
>     option in Geminispace, and that it's a viable option for a lot of (but
>     maybe not all) Gemini servers. It's enough to stop ISPs and sleazy
>     hotspot providers doing automated MITM attacks on all Gemini traffic,
>     which they could do if we just accepted whatever certificate came down
>     the line without any checks whatsoever - all it takes is one customer
>     with a TOFU client on a machine which routinely moves between networks
>     (say work and home, or home and the library, whatever) to reveal that
>     this is happening and raise the alarm.
>
>     Thinking about comparatively simple extensions on top of basic TOFU
>     which can add a little extra security is absolutely worth doing and I
>     encourage it and that's the spirit in which I've proposed a lot of these
>     things, like signing new certs with old keys, or pre-announcement of
>     cert roll-overs. But I think it makes more sense to ask of these simple
>     additional layers "do they add protection against some feasible attack
>     on vanilla TOFU?" and not "are there still some scenarios in which this
>     is vulnerable?", because the answer to the latter will always be "yes".
>
>     For the record, I would not recommend using Gemini for serious life and
>     death stuff, unless perhaps you're in a situation where you can meet
>     everybody involved face-to-face and confirm certificate fingerprints in
>     an offline way.
>
>
> > > -   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.
>
> Same response as above, I guess. Both of these approaches work best
> for sites that you visit "regularly", where "regular" is relative to
> certificate lifetime. If you're only going to check in with somewhere
> once every few years and have no contact with the people involved
> inbetween, it's very hard to maintain trust without involving third
> parties.
>
> > 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.
>
> I was surprised at how many people in #gemini said the other day that
> they had DNSSEC working for their domains! But, yes, this is perhaps
> the trickiest add-on discussed, because automating it would require
> hooking into an API for updating DNS records, and there are many of
> those in use so writing a cron-jobbable implementation of this approach
> which can be used by the majority of people is not straightforward.
> This might be something adopted by a relatively small number of servers
> who have some good reason to want to provide additonal assurance to
> their visitors.
>
> > > -   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 think this one is cool, too. :) I plan to code such an observatory
> (as a Gemini server itself, naturally!) one day. I like that it works
> well even for CA-signed certs, and that it requires nothing special on
> the part of the server admin.
>
> Conflict resolution would, I imagine, be configurable at the client's
> end. You could set it up to raise a red flag unless every observatory
> polled had seen the cert in question, or you could accept a cert if more
> than N observatories had seen it, whatever you thought was sensible. I
> don't think bootstrapping is needed, observatories can check which cert
> they see for a domain fairly quickly when they first receive a query
> about it (and thereafter add it to a list to to check on a recurring
> basis).
>
> Regarding "complicating the protocol a lot", I certainly don't imagine
> speccing this or any of the other ideas here as required. I don't
> think consulting remote TLS observatories will be a mainstream thing
> the average Geminiaut does. It will probably mostly be a toy for
> privacy and decentralisation geeks, and perhaps something that people
> involved in serious activism might pick up once said geeks have gotten
> it working smoothly.
>
> > I feel somewhat unsure about the problems I raised here btw, please correct me if
> > I've made any mistakes.
>
> I think everything you said, about possible shortcomings of my
> proposals, was factually correct! I think there was just a difference
> in expectations of what simple TOFU solutions can provide.
>
> Cheers,
> Solderpunk