-- Leo's gemini proxy

-- Connecting to gemi.dev:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

Hello all,

Mozz proposed an interesting idea to me on Github, which was removing expiry dates
from TOFU entirely.

I wrote a quick post on it, I'd appreciate it if you could read
it and offer your thoughts. I think this could help make things more secure on
Gemini, and possibly make TOFU and cert management more painless.

gemini://makeworld.gq/gemlog/2020-07-05-tofu-2.gmi

Thanks,
makeworld

Using the same keypair for a very long time is generally considered a
bad idea, as it increases both the risk of key compromise and the
duration for which a stolen key can be exploited.  There's also the
issue of ownership of domain names changing over long timespans, and
former legitimate domain owners being able to impersonate new legitimate
domain owners with old certificates.  Even CA certificates have expiry
dates.  I don't think we should be advising people to use certs which
last forever.

That said, for typical Gemini applications I don't think something like
a three year key/cert lifespan is necessarily a big problem, and would
certainly make TOFU issues less common.  In principle it doesn't make
much sense to rotate your TLS keys much more often than your server's
SSH keys, and let's be honest: how often do most of us do that?

One idea I had, which could be neat for people who are really serious
about good, long-term identity management without CAs, is the following:
generate a key pair, for use as an ephemeral signing key, and a
self-signed certificate for the public key with 100 years of validity.
Then generate 100 additional keypairs, and use the signing key to sign
certificates for them with a validity of, say, 1 year each, and
consecutive validity periods.  Permanently delete the signing key, but
keep the self-signed certificate.  Move all the 1 year keys to a USB
stick, and transfer them one at a time, as they become valid, to your
server.  For the next 100 years, serve up a two certificate long chain,
with the self-signed cert for the signing key, plus your currently
active 1 year cert signed with the signing key.  Once a client
TOFU-accepts the signing key's certificate, they'll be able to validate
all the annual key roll overs as originating from the same party, even
if they don't visit your site for 10 years at a time.  Someone who
breaks into your server can steal this year's key, but not any future
keys, because they're on the USB stick, so their ability to impersonate
you is strictly time-limited.  Nobody can steal the original signing key
and make their own certificate which will be accepted by TOFU clients,
because it's been deleted.  Hijacking this identity basically requires
stealing the physical USB key.  This sounds like a lot of work, but
generating all the keys and certs could be trivially automated.

Cheers,
Solderpunk

On 05.07.2020 18:27, colecmac at protonmail.com wrote:
> Hello all,
>
> Mozz proposed an interesting idea to me on Github, which was removing
> expiry dates
> from TOFU entirely.
>
> I wrote a quick post on it, I'd appreciate it if you could read
> it and offer your thoughts. I think this could help make things more
> secure on
> Gemini, and possibly make TOFU and cert management more painless.
>
> gemini://makeworld.gq/gemlog/2020-07-05-tofu-2.gmi
>
> Thanks,
> makeworld

By the way, I appreciate you writing this up, and also your earlier post
on TOFU which you shared here.

I've finally started work on my gentle TLS cert introduction, it's at
gemini://gemini.circumlunar.space/docs/tls-tutorial.gmi.  So far it's
just background stuff, but TOFU will feature eventually.  Keep an eye on
it over the next week or so.  Feedback welcome at any stage, though.

Cheers,
Solderpunk

Looks like it was a bad idea after all haha. I wasn't sure about it,
so thanks for showing some issues with it.

I will have to look at your USB example another time to understand it
fully, but it sounds interesting. Another optional security thing like
you explained with notaries?

> That said, for typical Gemini applications I don't think something like
> a three year key/cert lifespan is necessarily a big problem, and would
> certainly make TOFU issues less common. In principle it doesn't make
> much sense to rotate your TLS keys much more often than your server's
> SSH keys, and let's be honest: how often do most of us do that?

Maybe this is a better solution, everyone using longer term certs? It
still might not be enough though.

My thinking behind my original post was that the fewer valid reasons for
changing certs the better. If changing certs is very rare, then clients
can be more informative to the user, and say with more surety that there
is a MITM attack going on. How can we lessen the behaviour of just clicking
through any TOFU pop-up?

Thanks,
makeworld

On Sun Jul 5, 2020 at 8:48 PM CEST,  wrote:
> Looks like it was a bad idea after all haha. I wasn't sure about it,
> so thanks for showing some issues with it.
>
> Maybe this is a better solution, everyone using longer term certs? It
> still might not be enough though.
>
> My thinking behind my original post was that the fewer valid reasons for
> changing certs the better. If changing certs is very rare, then clients
> can be more informative to the user, and say with more surety that there
> is a MITM attack going on. How can we lessen the behaviour of just
> clicking through any TOFU pop-up?

Well, I think your overall thinking was very much in the right
direction, you just took it too far. :)

It's basically just a trade-off.  If certificates never, ever expire
then TOFU is very simple and clients will never have to show scary
messages under ordinary circumstances when everything is fine, but the
risk of the private key being stolen or broken (keys which are long
enough to be safe today will not be decades later) is very high, and if
it happens, the consequences last forever.  If certificates expire every
week, it's very hard to steal or crack a key before the corresponding
cert expires, but TOFU is unworkable without some extra complication on
top.  The best approach is somewhere in the middle.  The question is:
where?

On the web, certificate lifetimes are getting shorter and shorter - but
CAs have a strong financial incentive to be risk averse here, because
bad publicity around a single, long-lasting erroneously issued cert will
damage their reputation and hence business, possibly quite hard.  But
Gemini server admins using self-signed certs don't have that risk at
all.  Also, on the web, TLS is often protecting credit card details, or
access to email, or other things people have a strong incentive to
actively try to steal.  A personal Gemini host serving a gemlog is not
likely to be the target of serious efforts at compromise, so yet less
reason to be super cautious about key rotation.  For low-risk
applications, a five year certificate might be perfectly reasonable.

One could argue that longer lived certs actually help TOFU work, within
reason.  The longer a cert is in use, the more opportunity you have to
observe that cert being served to you from multiple different networks
(at home, at work, at the library, at the airport), which helps build
up your trust in it: getting MITMed once on a single network might be a
plausible risk.  Being consistently MITMed every time you visit a host,
from multiple locations, for years and years, is almost impossible, so
the longer you see the same cert, the more confident you can become that
when you blindly accepted the cert the very first time you weren't being
attacked.

Cheers,
Solderpunk

5 year certs sound like a good compromise to me. We can make client
messages sufficiently scary, seeing as a five year expiry will make
TOFU issue somewhat rare. Will you set that as a default for your
cert tool then?

Do you agree with my original recommendation that clients should
auto-accept any cert once the old one has expired? This seems relevant
here. I think it's nice for UX, although I see the obvious security risk.

makeworld

On Mon Jul 6, 2020 at 12:18 AM CEST,  wrote:
> 5 year certs sound like a good compromise to me. We can make client
> messages sufficiently scary, seeing as a five year expiry will make
> TOFU issue somewhat rare. Will you set that as a default for your
> cert tool then?

Maybe! ;)  I *do* plan to finally start work on that tool this week, by
the way.

Hopefully by 2025 we'll have agreed on a way to do smooth roll-overs
which is widely implemented!  If that does happen, and it's easily
automated (which I'd very much like it to be), maybe we can start
shifting towards less long-lived keys/certs for a extra peace of mind.

> Do you agree with my original recommendation that clients should
> auto-accept any cert once the old one has expired? This seems relevant
> here. I think it's nice for UX, although I see the obvious security
> risk.

In the absence of any other roll-over mechanism, yeah, this seems like
sane behaviour for a TOFU client.

Cheers,
Solderpunk

On 2020-07-05 15:18, colecmac at protonmail.com wrote:
> 5 year certs sound like a good compromise to me. We can make client
> messages sufficiently scary, seeing as a five year expiry will make
> TOFU issue somewhat rare. Will you set that as a default for your
> cert tool then?
>
> Do you agree with my original recommendation that clients should
> auto-accept any cert once the old one has expired? This seems relevant
> here. I think it's nice for UX, although I see the obvious security
> risk.

Also not that soon(-ish) Apple, Google & Mozilla browsers will _only_
accept certificates with a valid lifetime of maximum 1 year effectively
making this a "standard". While not necessarily relevant to Gemini
directly, it's something to keep in mind.

On Mon Jul 6, 2020 at 4:35 PM CEST, Laurens Vets wrote:

> Also not that soon(-ish) Apple, Google & Mozilla browsers will _only_
> accept certificates with a valid lifetime of maximum 1 year effectively
> making this a "standard". While not necessarily relevant to Gemini
> directly, it's something to keep in mind.

Yes, the CA/Browser forum (https://cabforum.org/) is really pushing for
shorter certificate lifespans.  It makes a good amount of sense if you
buy into the whole CA system.  I think under a TOFU scheme the structure
of incentives and risks is pretty different.  At least in these early
days where there's no widespread agreement and implementation on ways to
rotate keys more regularly without training users to always click
through any warning they see, I think using longer lived certs has
definite upsides.

Cheers,
Solderpunk

Good to hear, thanks! Now we just have to get all the servers
to switch over...

makeworld

??????? Original Message ???????
On Monday, July 6, 2020 8:55 AM, Solderpunk <solderpunk at posteo.net> wrote:

> On Mon Jul 6, 2020 at 12:18 AM CEST, wrote:
>
> > 5 year certs sound like a good compromise to me. We can make client
> > messages sufficiently scary, seeing as a five year expiry will make
> > TOFU issue somewhat rare. Will you set that as a default for your
> > cert tool then?
>
> Maybe! ;) Ido plan to finally start work on that tool this week, by
> the way.
>
> Hopefully by 2025 we'll have agreed on a way to do smooth roll-overs
> which is widely implemented! If that does happen, and it's easily
> automated (which I'd very much like it to be), maybe we can start
> shifting towards less long-lived keys/certs for a extra peace of mind.
>
> > Do you agree with my original recommendation that clients should
> > auto-accept any cert once the old one has expired? This seems relevant
> > here. I think it's nice for UX, although I see the obvious security
> > risk.
>
> In the absence of any other roll-over mechanism, yeah, this seems like
> sane behaviour for a TOFU client.
>
> Cheers,
> Solderpunk

On Sun, Jul 5, 2020 at 1:17 PM Solderpunk <solderpunk at posteo.net> wrote:
> Using the same keypair for a very long time is generally considered a
> bad idea, as it increases both the risk of key compromise and the
> duration for which a stolen key can be exploited. There's also the issue of
> ownership of domain names changing over long timespans, and former legitimate
> domain owners being able to impersonate new legitimate domain owners with old
> certificates. Even CA certificates have expiry dates.

Is this actually true for TOFU certificates? SSH fingerprints don't expire [1].

Servers can still rotate key pairs without introducing the attack vector of
expiring the old ones [2]. As soon as a client connects to a server and accepts
the new keypair, any old certs should automatically become invalid to that
client, because they're not the trusted "first-use" certificate anymore. It's
not like a CA system where there can be multiple valid keypairs live at the
same time. This is also true for transferring domain ownership.

An attacker can only continue to exploit a client until they visit the real
server. If the client never visits the real server, the attacker can just swap
out the expired certificate with a new self-signed certificate and it will look
like a harmless key rotation. Expiration doesn't gain you anything there.

I get the point about encryption algorithms becoming insecure over time and
private keys more likely to be stolen. I just don't understand the advantage to
key rotation + expiring the old keys vs. simple key rotation by itself.

[1] https://tools.ietf.org/html/rfc4716

[2] The attack vector being something like this: Your server rotates key pairs
every 60 days and issues certificates with a 90 day expiration. I visit your
server once and then don't come back for 90 days. My client sees that the
fingerprint in my local TOFU database is expired, and probably accepts whatever
server sends me. This scenario is dramatically lessened with > 1 year expiration
times, but why allow it to happen at all?

> One idea I had, which could be neat for people who are really serious
> about good, long-term identity management without CAs, is the following:
> generate a key pair, for use as an ephemeral signing key, and a
> self-signed certificate for the public key with 100 years of validity.
> Then generate 100 additional keypairs, and use the signing key to sign
> certificates for them with a validity of, say, 1 year each, and
> consecutive validity periods.  Permanently delete the signing key, but
> keep the self-signed certificate.  Move all the 1 year keys to a USB
> stick, and transfer them one at a time, as they become valid, to your
> server.  For the next 100 years, serve up a two certificate long chain,
> with the self-signed cert for the signing key, plus your currently
> active 1 year cert signed with the signing key.  Once a client
> TOFU-accepts the signing key's certificate, they'll be able to validate
> all the annual key roll overs as originating from the same party, even
> if they don't visit your site for 10 years at a time.  Someone who
> breaks into your server can steal this year's key, but not any future
> keys, because they're on the USB stick, so their ability to impersonate
> you is strictly time-limited.  Nobody can steal the original signing key
> and make their own certificate which will be accepted by TOFU clients,
> because it's been deleted.  Hijacking this identity basically requires
> stealing the physical USB key.  This sounds like a lot of work, but
> generating all the keys and certs could be trivially automated.

You would need some overlap in the validity periods to allow time to swap out
the keys on the server.

Honestly though, this sounds like an obtuse way to avoid using a CA. Once you
are employing certificate chains is it really self-signed anymore? Generate
your own CA with a 100-year expiration and stick *that* on the USB drive. You
could even maintain your own certificate revocation list! Utilizing CAs does
not need to imply trusting the root browser CAs.

best,
mozz

> Servers can still rotate key pairs without introducing the attack vector of
> expiring the old ones [2].

> I just don't understand the advantage to
> key rotation + expiring the old keys vs. simple key rotation by itself.

Thanks for chiming in mozz!

How can a server rotate a keypair and prove it's still the same server
as before, that there's not an MITM attack going on? This is a genuine question,
I haven't heard much about key rotation for TLS before. Could you explain or
send a link on how this works? I can't find much on it.

Thanks,
makeworld

> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of
> colecmac at protonmail.com
> How can a server rotate a keypair and prove it's still the same server as
> before, that there's not an MITM attack going on? This is a genuine question,
> I haven't heard much about key rotation for TLS before. Could you explain or
> send a link on how this works? I can't find much on it.

This thread feels like it's trying to hack certificate validation into
doing something for which it really wasn't intended, operating without a
CA. Getting this right is likely to be more complicated than any aspect of
the Gemini protocol itself.

The spec:
> the strongly RECOMMENDED approach is to implement a lightweight "TOFU"
certificate-pinning system which treats self-signed certificates as first-
class citizens. This greatly reduces TLS overhead on the network (only one
cert needs to be sent, not a whole chain) and lowers the barrier to entry
for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt
cron job, just make a cert and go).

Could I gently push back on the idea that getting an LE certificate is a
high barrier to entry? Configuring certbot is relatively easy and a known
quantity. Cleaning up after my private key is lost or exposed is an open
ended problem with no easy solutions. I know there is a diversity of
opinions/priorities but my vote would be to lean on the regular CA
infrastructure so that we don't have to tussle with all of the scenarios
currently being discussed.

More broadly, Gemini is a magnificent hack to co-opt the best of both
gopher and the web into a carefully calibrated new thing, leaning on
existing technologies like URLs, MIME types and TLS for expedience.
LetsEncrypt is a magnificent hack to the CA system, providing all the
benefits to us at no monetary cost, and that was no small undertaking. I
don't think it should fall to Gemini, and therefore the implementors of
Gemini clients and servers, to "fix" TLS trust. A good solution, once it
is actually adopted, is likely to apply to all TLS servers rather than
Gemini alone. Provided we are using TLS libraries we can take advantage of
whatever that happens to be.

If nothing else, clients could attempt to verify the provided cert/chain
against the system's trusted root CAs. If this takes precedence over TOFU
it offers an escape hatch for anybody who wanted to try the self-signed
thing and then it didn't work out. Nothing I've suggested here is
_contrary_ to the spec as it stands - it's just a question of what people
do by default, which hopefully won't set them up for failure later.

Cheers, Tom

On Tue Jul 7, 2020 at 6:26 AM CEST, Thomas Karpiniec wrote:

> Could I gently push back on the idea that getting an LE certificate is a
> high barrier to entry? Configuring certbot is relatively easy and a
> known quantity. Cleaning up after my private key is lost or exposed is
> an open ended problem with no easy solutions. I know there is a
> diversity of opinions/priorities but my vote would be to lean on the
> regular CA infrastructure so that we don't have to tussle with all of
> the scenarios currently being discussed.

This opinion has been expressed in the past - in fact, by Michael Lazar
if I remember rightly?  The extent to which Geminispace at large has
been interested in trying to breakaway from the "centralised oligarchy
of CAs" has changed.  I'd love to have detail stats on the actual
proportion of servers using self-signed vs CA-signd certs over time!
There seems to be more enthusiasm behind TOFU at the moment than
at other times in the relatively recent past.

The spec is deliberately, for now, quite open ended on this.  I didn't
want to force people to implement TOFU, which has proven less trivial
than I first imagined.  But I also didn't want server operators who do
choose to experiment with it to become second class citizens of
Geminispace, with most clients throwing up scary warnings every time.

> If nothing else, clients could attempt to verify the provided cert/chain
> against the system's trusted root CAs. If this takes precedence over
> TOFU it offers an escape hatch for anybody who wanted to try the
> self-signed thing and then it didn't work out. Nothing I've suggested

In generally agree with you here.  This allows folks without
philosophical/political axes to grind to just setup certbot and know it
will work smoothly (which it doesn't with pure TOFU clients, which will
trigger warnings regularly)  The only reason AV-98 doesn't do this, and
forces you to manually switch between the two modes, is that the
standard Python ssl module doesn't allow it (at least not gracefully,
without making a new connection after one fails).

> This thread feels like it's trying to hack certificate validation into
> doing something for which it really wasn't intended, operating without a
> CA. Getting this right is likely to be more complicated than any aspect
> of the Gemini protocol itself.

I have been thinking this myself lately.  Not that I want to give up on
TOFU, but that all the more clever/elegant ways of doing it which
involve certificate chains are actually not the way to go: they might be
solid security wise, but no TLS library is going to support them out of
the box.  They *might* be easily implemented with a library which
exposes signature validation functions nicely, but those will be rare,
and further more programmers who understand how to do that properly will
be even rarer, running the risk of bad implementations.

My current thinking is that any recommended approach should avoid
treating certificates as anything more than than opaque binary blobs as
much as possible (for the purposes of trust management, I mean).  The
various ideas around serving future certificates on a well-known
endpoint for some time before they become valid fits in with this.  It
just involves fetching a pile of bytes and hashing it, no understanding
of keys/signing on the part of the client author required...

> A good solution, once it
> is actually adopted, is likely to apply to all TLS servers rather than
> Gemini alone.

I'm not too sure about this.  Solutions which work in an environment
dominated by dissemination of publically available information
(Geminispace, I hope) may not work acceptably well in an environment
dominated by private conversations (email, and a lot of the web).  I
suspect it's a lot easier to come up with something relatively simple
that works for us which most other TLS servers will be disinterested in.

Cheers,
Solderpunk

On Tue Jul 7, 2020 at 5:20 AM CEST, Michael Lazar wrote:

> Servers can still rotate key pairs without introducing the attack vector
> of
> expiring the old ones [2]. As soon as a client connects to a server and
> accepts
> the new keypair, any old certs should automatically become invalid to
> that
> client, because they're not the trusted "first-use" certificate anymore.
> It's
> not like a CA system where there can be multiple valid keypairs live at
> the
> same time. This is also true for transferring domain ownership.

You're right that TOFU clients should in general only have a single
actively trusted key on record for each server.

I guess I see the main utility of explicit expiration dates in this
context as being a kind of promise from the sever admin that "I have no
plans to do a key rotation for about this length of time".  This means
that apparent MITM attacks happening at a time when there's a lot of
validity left can be treated with much higher suspicion.

> You would need some overlap in the validity periods to allow time to
> swap out
> the keys on the server.

Sure.

> Honestly though, this sounds like an obtuse way to avoid using a CA.
> Once you
> are employing certificate chains is it really self-signed anymore?
> Generate
> your own CA with a 100-year expiration and stick *that* on the USB
> drive.

Well, that's sort of what that idea is, at core: being your own CA.
TOFU clients treating certificates that they've trusted once as CAs
of very limited power (only able to sign future certs for that one
domain, and perhaps only good for a single signature) is an interesting
way to get from "trusting on blind faith everytime a new cert comes down
the line" to "trusting on blind faith once at the very beginning and
then building up strong trust over time that you're always interacting
with the same party".  That second situation, if we can get there, is, I
would argue, good enough for Geminispace - and, arguably, a lot more
like how trust in the real world works.

Cheers,
Solderpunk

A proposal: "TOFU-TOTS".  You know, like tater tots, but without
potatoes in them.  Or rather, trust-on-first-use augmented by
trust-over-time-and-space.

Desiderata:

* Limit actions of blind faith to a single point in time.
* Allow ever more trust to slowly, organically build up after that
  point.
* Permit fully automated regular key rotation on servers.
* Don't require client authors to write code to validate signatures.

Assumptions:

* MITM attacks limited to a single network for a short duration of time
  are a plausible threat, but MITM attacks which target an individual
  user no matter which network their using are extremely hard, and even
  on a single network (home ISP, say), MITM attacks which last for
  months or years require dedication and are more likely to be
  whistleblown.

Quick description:

* Certs last for several years
* The very first time you connect to a server (or the first time after
  so long that all your previous knowledge about that server is badly
  out of date), blindly accept whatever you get.
* New keys and certs are generated 1 year before they become valid
  (consecutive certs have maybe 1 month of overlapping validity to allow
  for change over)
* New certs, or their fingerprint, are served on a well-known end point
  immediately after generation, i.e. for roughly one year before their
  validity begins.
* TOFU-TOTS clients have a "trust maintenance" procedure which should be
  run, say, once a month, or maybe every 3 months.  Fancy clients can do
  this automatically in the background on a separate thread.  Simple
  clients can just keep track of when this was last run, check that
  against the current date on startup and say "Hey, you haven't done
  trust maintenance in a while, wanna do it now?  Y/N" without bothering
  with threads.  Users who are security nerds should be able to run it
  on demand whenever they like.
* Trust maintenance involves:
    - Removing expired certificates from the TOFU database
    - If a non-expired cert in the DB has less than 1 year of validity
      left, hit the server's well known endpoint and, assuming that
      transaction takes place using a previously trusted cert, store the
      cert/fingerprint you see at that endpoint, along with a counter of
      how many times you've observed it.
    - If the same well known endpoint ever serves up different future
      certificates while the same current certificate is valid, "warn
      hard".
* When a new cert comes down the line, "warn hard" if it's completely
  out of the blue.  Accept it silently if it's been pre-advertised by
  the appropriate server at least N times previously (perhaps "warn
  softly" if it's been advertised less than N times but at least once),
  and delete that server's previously trusted cert (possibly
  incrementing a counter of the number of trusted roll-overs this server
  has achieved, permitting the option to "warn extremely hard" if we
  ever get an out of the blue cert change for a server which has
  previously done the right thing multiple times).

Properties:

* Meets all desiderata above.
* If I steal your private key, I can straightforwardly use this in
  attacks only until your current cert expires - not forever, as
  would be the case with 100 year certs.
* In order to extend the time I can exploit the stolen key, I need to
  successfully MITM every possible future victim of my attacks, for
  multiple executions of their trust maintenance routine, which happen
  at unpredictable times, over the course of a year, possibly from
  multiple different networks, and I can't do this if I steal your key
  in its final year of validity, because victims will have already
  picked up the true next certificate at least once - this is a big
  improvement over roll-over schemes where new certificates are signed
  with the private key of the old certificate, in which case once I've
  stolen your key it's trivial for me to just sign myself future
  certificates which anybody will accept - and I can keep doing this,
  forever, spinning a single key breach out indefinitely despite
  regular rotation!
* Clients are, as always, vulnerable to undetected MITM attacks on that
  very first connection, but such an attack can be fairly easily
  discovered after the fact (providing a strong disincentive for e.g.
  commercial ISPs to do them regularly) unless the attacker commits to a
  clean exit by MITMing you multiple times in the future to feed you the
  legitimate next cert.

Right now, I think this provides pretty good robustness against MITM
attacks relative to how conceptually complicated it is - nothing is
involved on the server side except generating stand-alone self-signed
certs and copying them at the right time into the document root, which
is very easily automated, and nothing is involved on the client side
except storing hashes of entire certs in a DB and checking expiry dates.
Client authors never have to write their own signature validation code,
so this can be done even with TLS libraries that don't make that easy.
It also has the advantage of keeping TLS network overhead as low as
possible by having servers only ever send a single cert.

But, maybe I've overlooked something.  Feedback welcome.

Cheers,
Solderpunk

On Tue, Jul 07, 2020 at 11:30:20AM +0200, Solderpunk wrote:
> I'd love to have detail stats on the actual proportion of servers
> using self-signed vs CA-signd certs over time! There seems to be
> more enthusiasm behind TOFU at the moment than at other times in the
> relatively recent past.

I can gladly start tracking this with the next GUS crawl, but we're
getting beyond my expertise. I have a very lightly modified version
[0] of Jason McBrayer's gusmobile [1] (in Python) that I think has
been, thankfully, the sole arbiter of all things TLS for GUS. If
anyone is interested in altering that code, or helping me figure out
how to alter that code, to return info on self-signed vs CA-signed
distinctions, we could get statistics on this soon.

[0] https://git.sr.ht/~natpen/gusmobile
[1] https://git.carcosa.net/jmcbray/gusmobile/

Natalie Pendragon <natpen at natpen.net> writes:

> I can gladly start tracking this with the next GUS crawl, but we're
> getting beyond my expertise. I have a very lightly modified version
> [0] of Jason McBrayer's gusmobile [1] (in Python) that I think has
> been, thankfully, the sole arbiter of all things TLS for GUS. If
> anyone is interested in altering that code, or helping me figure out
> how to alter that code, to return info on self-signed vs CA-signed
> distinctions, we could get statistics on this soon.
>
> [0] https://git.sr.ht/~natpen/gusmobile
> [1] https://git.carcosa.net/jmcbray/gusmobile/

If your modifications are generally useful, would you be willing to
submit a pull request (or just a git-send-email patch)? I've kind of
neglected gusmobile, to the point that it has an actual long-standing
bug that has to be worked around for the most trivial use-case. I've
been meaning to fix it, but I have so little time for hobby hacking.

--
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

> A proposal: "TOFU-TOTS". You know, like tater tots, but without
> potatoes in them. Or rather, trust-on-first-use augmented by
> trust-over-time-and-space.

I like this proposal, and I want to digest it more fully later, but
it also seems like this complicates what's already the most complicated
part of Gemini. Is this an optional special idea, like notaries, or are
you hoping this gets more widespread use?

Personally, I like the simpler ideas that have been used so far, combined
with something like 5 year certs.


makeworld

P.S. Can anyone explain or give me a link on TLS key rotation? How is it
different from changing certs?

I really like the way of announcing future certificates by putting them
in a well known location (not just their fingerprint, as this requires
either the server or the client (probably both) to support multiple
fingerprinting algorithms because even if we agree on one hash algorithm
today, there are already people trying to break it and updating that
will be a mess).

That said the name of this well known location should include the name
tls somewhere to keep the door open for potential tls replacements (I
think TLS is a great choice, but if something else emerges I don't want
to bother with legacy magic paths).

There are also three other certificates besides the future one that
could/should be served at a well known location:

- Alternative (Backup) certificates for both the current and future
certificate, that can be used when the key behind the original
certificate was compromised, they have to be valid for the same
time-span as the originals and become the originals as soon as they are
used. The private keys of these of course should be kept in cold storage
until they are needed. Clients should at least notify the user when they
see a backup certificate being used and treat the original certificate
as untrusted but not delete it immanently (as it is possible that only
the backup key was compromised and still be used by the original
server). The user must have the ultimate choice which certificate to
trust after a backup certificate has been used as which certificate is
trustable should be communicated out of band in such a case.

- The currently used certificate that could be checked by clients to
detect general purpose dragnet TLS interception, that knows nothing
about Gemini and its conventions (basically what I'd do if I was the
dictator of a surveillance state to monitor and censor internet access
for thousands or millions of people). This too could also be useful if
some TLS alternative emerges, you already trust one key the server uses,
so why not use that to get the other keys it uses. Another possible
usecase is that someone really concerned could use any niche proxy
protocol to fetch the certificate the server should have (I know
portal.mozz.us already has a feature that allows one to fetch the server
certificate but proxy.vulpes.one doesn't and a gemini to gemini proxy
would have to use a well known endpoint to fetch the certificate anyway
(but that wouldn't allow you to check if the proxy got MitMd by a lazy
TLS interception)) To make this even more of a pain for attackers each
server could have (a) secondary endpoint(s) that is/are only
communicated in human readable form (i.e. generating a captcha image
that contains the filename in a nonstandard location) that changes on a
regular basis) that too serve(s) the certificate used with the
possibility for a security focused client to have a tool that can
automatically check against the certificates it trusts and the one it
received from the server. (All of this can be realized by adding two
configuration options to a Gemini server, or if the server doesn't
support that symlinks should work as well).

Again, I'm just throwing Ideas around hoping that they'll be considered
useful.

Have a nice Evening

- Baschdel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200707/f3df
19bb/attachment-0001.htm>

On Tue, Jul 07, 2020 at 10:03:31AM -0400, Jason McBrayer wrote:
> If your modifications are generally useful, would you be willing to
> submit a pull request (or just a git-send-email patch)? I've kind of
> neglected gusmobile, to the point that it has an actual long-standing
> bug that has to be worked around for the most trivial use-case. I've
> been meaning to fix it, but I have so little time for hobby hacking.

Sure, patches incoming! You can pick and choose anything that looks
useful, but honestly the reason I hadn't already submitted these
changes upstream is that most of them are hacks to make Gusmobile and
GUS play well together.

Natalie Pendragon <natpen at natpen.net> writes:

> On Tue, Jul 07, 2020 at 10:03:31AM -0400, Jason McBrayer wrote:
>> If your modifications are generally useful, would you be willing to
>> submit a pull request (or just a git-send-email patch)? I've kind of
>> neglected gusmobile, to the point that it has an actual long-standing
>> bug that has to be worked around for the most trivial use-case. I've
>> been meaning to fix it, but I have so little time for hobby hacking.
>
> Sure, patches incoming! You can pick and choose anything that looks
> useful, but honestly the reason I hadn't already submitted these
> changes upstream is that most of them are hacks to make Gusmobile and
> GUS play well together.

Thanks, I super appreciate your work!

--
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

> On Jul 7, 2020, at 11:30, Solderpunk <solderpunk at posteo.net> wrote:
>
> My current thinking is that any recommended approach should avoid
> treating certificates as anything more than than opaque binary blobs as
> much as possible

Perhaps of interest:

Using Raw Public Keys in Transport Layer Security (TLS)
https://tools.ietf.org/html/rfc7250

On Wed, Jul 8, 2020 at 4:57 PM Petite Abeille <petite.abeille at gmail.com> wrote:
>
> Perhaps of interest:
>
> Using Raw Public Keys in Transport Layer Security (TLS)
> https://tools.ietf.org/html/rfc7250

Yes. Looks interesting, and it goes in the right direction.
Unfortunately, the RFC is already quite old (2014)  and according to
Wikipedia, it is only supported by GnuTLS (I didn't check directly).

Do you know if it is already used in some visible applications?

Phil

On Wed, Jul 8, 2020 at 6:25 PM Phil Leblanc <philanc at gmail.com> wrote:
> according to Wikipedia, [RFC 7250] is only supported by GnuTLS

see https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

> Phil

> On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
>
> Yes. Looks interesting, and it goes in the right direction.
> Unfortunately, the RFC is already quite old (2014)  and according to
> Wikipedia, it is only supported by GnuTLS (I didn't check directly).
>
> Do you know if it is already used in some visible applications?

Hmm, no :) Just stumbled upon it on the openssl mailing list, where
someone was asking if it was supported:

RFC 7250 raw public keys?
https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html


There is an open issue for it:

Raw Public Key (RFC 7250) support
https://github.com/openssl/openssl/issues/6929


mbedtls seems to have something:

Support Raw Public Key mode (RFC7250)
https://github.com/ARMmbed/mbedtls/pull/336

Thanks for sharing this!  I will read it closely.  It's a shame if it's
not widely implemented, but there may well still be good ideas in there,
or details we've overlooked.

Cheers,
Solderpunk

On Wed Jul 8, 2020 at 11:27 PM CEST, Petite Abeille wrote:
>
>
> > On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
> >
> > Yes. Looks interesting, and it goes in the right direction.
> > Unfortunately, the RFC is already quite old (2014)  and according to
> > Wikipedia, it is only supported by GnuTLS (I didn't check directly).
> >
> > Do you know if it is already used in some visible applications?
>
> Hmm, no :) Just stumbled upon it on the openssl mailing list, where
> someone was asking if it was supported:
>
> RFC 7250 raw public keys?
> https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html
>
>
> There is an open issue for it:
>
> Raw Public Key (RFC 7250) support
> https://github.com/openssl/openssl/issues/6929
>
>
> mbedtls seems to have something:
>
> Support Raw Public Key mode (RFC7250)
> https://github.com/ARMmbed/mbedtls/pull/336

On Tue Jul 7, 2020 at 4:34 PM CEST,  wrote:

> I like this proposal, and I want to digest it more fully later, but
> it also seems like this complicates what's already the most complicated
> part of Gemini. Is this an optional special idea, like notaries, or are
> you hoping this gets more widespread use?

Oh!  I had thought of this as a relatively simple idea, simpler than
anything involving signatures to validate new keys.

> Personally, I like the simpler ideas that have been used so far,
> combined
> with something like 5 year certs.

What are the simpler ideas?  Just straight up TOFU with a scary message
five years later?

Cheers,
Solderpunk

> On Jul 9, 2020, at 00:18, Solderpunk <solderpunk at posteo.net> wrote:
>
> Thanks for sharing this!  I will read it closely.  It's a shame if it's
> not widely implemented, but there may well still be good ideas in there,
> or details we've overlooked.

Another link, as a counterexample of what we are trying to escape from:

Path Building vs Path Verifying: The Chain of Pain
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pa
in-9fbab861d7d6

The Chain of Pain! :D

> On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
>
> GnuTLS

GNU: A Heuristic for Bad Cryptography
https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/

Ah!

On Wed, Jul 8, 2020 at 9:27 PM Petite Abeille <petite.abeille at gmail.com> wrote:
>

> mbedtls seems to have something:
>
> Support Raw Public Key mode (RFC7250)
> https://github.com/ARMmbed/mbedtls/pull/336

I downloaded mbedtls (the development branch) one week ago
(2020-07-01). I grepped through the tree and found no sign of RFC7250
or RPK :-(

On Wed, Jul 8, 2020 at 11:08 PM Petite Abeille <petite.abeille at gmail.com> wrote:
>
> GNU: A Heuristic for Bad Cryptography
> https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/
>
> Ah!

Nice :-)

On Wednesday, July 8, 2020 6:19 PM, Solderpunk <solderpunk at posteo.net> wrote:

> [...]
> > Personally, I like the simpler ideas that have been used so far,
> > combined
> > with something like 5 year certs.
>
> What are the simpler ideas? Just straight up TOFU with a scary message
> five years later?


Yes, I see that as a lot simpler. It doesn't require a well known endpoint, or
a background service for clients, etc. But I still like the idea.


makeworld

> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk
> A proposal: "TOFU-TOTS".  You know, like tater tots, but without
> potatoes in them.  Or rather, trust-on-first-use augmented by
> trust-over-time-and-space.

Setting aside that I already put my support behind the oligarchy, this is
an interesting problem and I'll weigh in. :)

I agree that that this proposal would provide fairly effective protection
against MITM. I worry that it is so unusual that it would push newbies
away from setting up gemini servers. Faced with regular rotation
requirements I suspect that many people would automate the process with
cronjobs, meaning that the keys for the next certificate are sitting right
there on the server ready to be nabbed.

More annoyingly, suppose the current private key is compromised and the
legitimate server owner realises it - they don't have any good options.
One is to put up with being spoofable until their next-advertised
certificate becomes valid, which may be 10 months in the future. Otherwise
they could do an out-of-turn certificate rotation, which clients will warn
on just as harshly as any other unexpected change. (Further down the
thread, Baschdel suggested backup certificates to alleviate this. But what
if you're compromised twice? To me the complexity creep feels
disproportionate to the advantages.)

A suggestion: what if instead of publishing a future certificate, we
publish our own CA certificate, which is used to sign our server
certificates? A client should cache this CA certificate permanently and
use it to verify all future requests to that domain. A diligent system
administrator will keep their CA key material offline. Someone who doesn't
care so much can just generate everything on their server.

* Client logic is simpler
* Keys and certificates can be rotated at will by the sysadmin and they
can choose whatever expiry they are comfortable with
* Relies on familiar concepts of TLS trust ("oh I'm my own CA, okay") and
sysadmins can choose their own level of caution
* Uses the existing feature of TLS libraries to verify a connection
against a given CA. Clients don't have to handle public keys or
fingerprints - they just download the CA certificate and feed it into their TLS library.
* Combines neatly with LetsEncrypt-style certificate management - you are
just adding one extra trusted CA. If it can be verified by either that, or
one of the normal roots, then you're okay.
* Only slightly more complicated openssl commands required when setting up a server

Cheers, Tom

If you're willing to look at unusual uses of TLS, I'll mention that there's
also an RFC for OpenPGP-based TLS encryption. This is not a recommendation!

https://tools.ietf.org/html/rfc6091

That would allow web-of-trust based infrastructure. But as there are no
widespread implementations, it will be a pain to use in practice.

In my very humble opinion, a community-based distributed trust system is
safer than TOFU and more suitable for non-commercial use than CA based PKI.
But in practice *any* TLS is much, much safer than plaintext as it
completely prevents eavesdropping without a full-fledged MitM attack.

A more practical way of building a web of trust upon TOFU would be for
browsers to export cert fingerprint lists that people can share on their
sites. These could be compared and imported, and with some human
interaction we should notice when MitM attacks start happening in practice.

-Hannu

On Thu, 9 Jul 2020 at 01:19, Solderpunk <solderpunk at posteo.net> wrote:

> Thanks for sharing this!  I will read it closely.  It's a shame if it's
> not widely implemented, but there may well still be good ideas in there,
> or details we've overlooked.
>
> Cheers,
> Solderpunk
>
> On Wed Jul 8, 2020 at 11:27 PM CEST, Petite Abeille wrote:
> >
> >
> > > On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
> > >
> > > Yes. Looks interesting, and it goes in the right direction.
> > > Unfortunately, the RFC is already quite old (2014)  and according to
> > > Wikipedia, it is only supported by GnuTLS (I didn't check directly).
> > >
> > > Do you know if it is already used in some visible applications?
> >
> > Hmm, no :) Just stumbled upon it on the openssl mailing list, where
> > someone was asking if it was supported:
> >
> > RFC 7250 raw public keys?
> > https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html
> >
> >
> > There is an open issue for it:
> >
> > Raw Public Key (RFC 7250) support
> > https://github.com/openssl/openssl/issues/6929
> >
> >
> > mbedtls seems to have something:
> >
> > Support Raw Public Key mode (RFC7250)
> > https://github.com/ARMmbed/mbedtls/pull/336
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/3128
bd33/attachment.htm>

A thought from one without enough knowledge to have a right to thoughts:

Getting broad acceptance of Gemini both theoretically as a viable
standard and practically as a growing community is important. Having
community members developing their own clients and servers - not so much.

I am sure I will always be using a client which someone else wrote, just
as I use a  web browser someone else wrote. And I am dead certain I will
never try to write my own server, as I will never try to write my own
Apache.

Best to all,

Terry B.


On 07/08/2020 08:39 PM, Thomas Karpiniec wrote:
>> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk
>> A proposal: "TOFU-TOTS".  You know, like tater tots, but without
>> potatoes in them.  Or rather, trust-on-first-use augmented by
>> trust-over-time-and-space.
> Setting aside that I already put my support behind the oligarchy, this
is an interesting problem and I'll weigh in. :)
>
> I agree that that this proposal would provide fairly effective
protection against MITM. I worry that it is so unusual that it would push
newbies away from setting up gemini servers. Faced with regular rotation
requirements I suspect that many people would automate the process with
cronjobs, meaning that the keys for the next certificate are sitting right
there on the server ready to be nabbed.
>
> More annoyingly, suppose the current private key is compromised and the
legitimate server owner realises it - they don't have any good options.
One is to put up with being spoofable until their next-advertised
certificate becomes valid, which may be 10 months in the future. Otherwise
they could do an out-of-turn certificate rotation, which clients will warn
on just as harshly as any other unexpected change. (Further down the
thread, Baschdel suggested backup certificates to alleviate this. But what
if you're compromised twice? To me the complexity creep feels
disproportionate to the advantages.)
>
> A suggestion: what if instead of publishing a future certificate, we
publish our own CA certificate, which is used to sign our server
certificates? A client should cache this CA certificate permanently and
use it to verify all future requests to that domain. A diligent system
administrator will keep their CA key material offline. Someone who doesn't
care so much can just generate everything on their server.
>
> * Client logic is simpler
> * Keys and certificates can be rotated at will by the sysadmin and they
can choose whatever expiry they are comfortable with
> * Relies on familiar concepts of TLS trust ("oh I'm my own CA, okay")
and sysadmins can choose their own level of caution
> * Uses the existing feature of TLS libraries to verify a connection
against a given CA. Clients don't have to handle public keys or
fingerprints - they just download the CA certificate and feed it into their TLS library.
> * Combines neatly with LetsEncrypt-style certificate management - you
are just adding one extra trusted CA. If it can be verified by either
that, or one of the normal roots, then you're okay.
> * Only slightly more complicated openssl commands required when setting up a server
>
> Cheers, Tom

On Thu Jul 9, 2020 at 1:25 AM CEST,  wrote:

> > What are the simpler ideas? Just straight up TOFU with a scary message
> > five years later?
>
>
> Yes, I see that as a lot simpler. It doesn't require a well known
> endpoint, or
> a background service for clients, etc. But I still like the idea.

I guess it will always be up to individual server admins to decide how
they want to balance the effort involved in different setups against
what kind of user experience they're happy for their visitors to have,
and how they perceive their risk of someone trying to impersonate them.
All we can really do is lay out the various options along the scale, and
perhaps recommend one in particular as the "go to" choice for people who
don't feel up to making the decision.

Cheers,
Solderpunk

-- Response ended

-- Page fetched on Thu May 23 20:45:54 2024