💾 Archived View for gemi.dev › gemini-mailing-list › 000789.gmi captured on 2024-05-26 at 16:41:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi! I think that people find TOFU controversial because it removes the ability for clients to verify the authenticity of servers they've never connected to before and it prevents servers from ever being able to change certificates. I think that both of these issues are solvable while keeping with the spirit of Gemini. xq (on IRC) proposed the concept of 'distributed trust' lists, which are simply lists associating domains with public keys (i.e. their hashes). Gemini servers and clients can then distribute and verify trust lists, and can even merge trust lists from different sources together. This neatly solves the first problem, by allowing clients to check their trust lists to determine the public key of a server and so to authenticate them even in the first connection. Here's xq's post about their idea: => gemini://random-projects.net/blog/2021-03-03-distributed-trust.gemini I propose an extension to this, which allows servers to announce their intention (in a verifiable way) to change certificates in the near future. Essentially, servers now provide (over Gemini) a '/.pubkey' URL where they serve the hash of the public key they will use in the near future (which may be the same as the public key they use right now). Clients can periodically request '/.pubkey' to check if the server intends to change their pubkey soon. In later connections, the server will either use the current pubkey or the previously-announced future pubkey - if clients see the latter being used, they know that the server has transitioned to using this future pubkey and so can drop the previous pubkey. This provides a safe method for verifying server certificates, even when they are rotated. There are a few more details, which you can read about on my blog post: => gemini://gemini.ctrl-c.club/~aravk/blog/2021-03-04-distributed-trust.gmi The exact format used and various smaller details can be tweaked as we see fit, but I'm looking for thoughts on the general concept. I know that there are some voices for permanently using a single certificate, but I personally prefer rotating certs and I think that the perma-cert people don't lose out at all in this. Any (constructive) feedback is appreciated. ~aravk | ~nothien
I disagree with any feature which involves the client periodically requesting a specific file from the server, for reasons we should probably not re-hash. Why use a technical solution when a social solution would be suitable? A much easier way is to simply announce the upcoming cert change in your gemlog.
Hello, > On Mar 5, 2021, at 13:33, nothien at uber.space wrote: > > => gemini://random-projects.net/blog/2021-03-03-distributed-trust.gemini > => gemini://gemini.ctrl-c.club/~aravk/blog/2021-03-04-distributed-trust.gmi Thank you for sharing. Appreciating the engagement. Not sure how to put it "constructively", but this looks... unfinished. But ok, let's suspend disbelieve for a second, and assume you have solved the decentralized trust conundrum on your own ? minus blocks, minus chains, plus something. First off, congrats! :) This is a major achievement - a breakthrough in computer science, as understood by the security community at large. Question: are you going to publish a proper white paper on it ? and have it peer reviewed? By "peer", I don't means some pesky insects on some god forsaken corner of the interweb. More like proper scrutiny. Probing. By actual security experts. Sorry to rain on your parade, but truly, I cannot muster anything supportive to say at all. Apologies. Nothing personal. Meanwhile, perhaps I could interest you in keybase: https://en.wikipedia.org/wiki/Keybase Specifically, their take on identity proofs. Perhaps of interest. ?0?
> On Mar 5, 2021, at 13:47, Drew DeVault <sir at cmpwn.com> wrote: > > Why use a technical solution when a social solution would be suitable? A > much easier way is to simply announce the upcoming cert change in your > gemlog. Because of the scale of the network. Such "social" approach works in the small, but doesn't scale. It simply moves the problem around: now the burden of proof is on the user to check some sort of "announcements" and act on it meaningfully. Each and every single time. In my personal experience, this will never fly. YMMV for sure. ?0?
> On Mar 5, 2021, at 13:33, nothien at uber.space wrote: > > Any (constructive) feedback is appreciated. This is the only thing I could find: https://www.gocomics.com/nonsequitur/2021/03/05 ?0?
"Drew DeVault" <sir at cmpwn.com> wrote: > I disagree with any feature which involves the client periodically > requesting a specific file from the server, for reasons we should > probably not re-hash. The intention is not for ordinary clients to have to do this (unless they want to), but for servers distributing these trust lists to perform this verification/update. > Why use a technical solution when a social solution would be suitable? > A much easier way is to simply announce the upcoming cert change in > your gemlog. Petite Abeille has addressed this neatly: > Because of the scale of the network. > > Such "social" approach works in the small, but doesn't scale. > > It simply moves the problem around: now the burden of proof is on the > user to check some sort of "announcements" and act on it meaningfully. > Each and every single time. ~aravk | ~nothien
On Fri, Mar 05, 2021 at 01:33:49PM +0100, nothien at uber.space <nothien at uber.space> wrote a message of 44 lines which said: > I propose an extension to this, which allows servers to announce > their intention (in a verifiable way) to change certificates in the > near future. Essentially, servers now provide (over Gemini) a > '/.pubkey' URL where they serve the hash of the public key they will > use in the near future (which may be the same as the public key they > use right now). And Drew deVault who said that using Let's Encrypt was too complicated :-) Anything that requires such operations does not seem to fit with the principles of Gemini. (And I speak from experience managing DNSSEC key rollovers.) Also, this proposal does not address unplanned emergency changes (such as one triggered by a compromise of the private key). They are one of the biggest problems with TOFU.
On Fri, Mar 05, 2021 at 01:33:49PM +0100,
nothien at uber.space <nothien at uber.space> wrote
a message of 44 lines which said:
> I propose an extension to this, which allows servers to announce
> their intention (in a verifiable way) to change certificates in the
> near future.
Gemini already has one way to announce this intention. To quote the
spec, "If the certificate is not the one previously received, BUT THE
PREVIOUS CERTIFICATE'S EXPIRY DATE HAS NOT PASSED, the user is shown a
warning". So, to announce your intention to change the certificate,
just say so in the expiration date (notAfter field).
Agunua <gemini://gemini.bortzmeyer.org/software/agunua/> does it in a
more liberal way, accepting a change if there is less than 10 % of the
former certificate life remaining:
# We accept a slack of 10 % of the certificate lifetime, or 7 days, whatever is smaller.
slack = old_lifetime/10
if datetime.timedelta(days=7) < old_lifetime/10:
slack = datetime.timedelta(days=7)
if self.keystring != old_key:
if datetime.datetime.utcnow() >= (old_expiration - slack):
pass # OK, it is expired or soon to be
else:
error = "Former public key at %s was %s, new one is %s. ...
On Mon, 8 Mar 2021 at 13:28, Stephane Bortzmeyer <stephane at sources.org> wrote: > Gemini already has one way to announce this intention. To quote the > spec, "If the certificate is not the one previously received, BUT THE > PREVIOUS CERTIFICATE'S EXPIRY DATE HAS NOT PASSED, the user is shown a > warning". So, to announce your intention to change the certificate, > just say so in the expiration date (notAfter field). In other words broadcast to potential attackers when the best time to do a MitMA is :) If clients silently accept new certificates this gets even worse, because it opens a window where the attack can happen without anyone knowing. A certificate that's valid for 90 days, ending 9 days from now, can silently be replace by another certificate with the same not-valid-before and not-valid-after, allowing the attacker 9 days of unnoticed operation. I think we've pretty much laid out all the pros and cons of TOFU as a validation scheme. I personally believe there is very little benefit to trying to make it more secure, compared to the added complexity. We need to clarify the spec around what TOFU means for clients and servers, and that includes removing advice like "check not-valid-before, hostname, and not-valid-after" and that certificates should be rotated. Or we need to decide to not use TOFU. I'm not going to reiterate the alternatives I see, but suffice to say that I think this is an issue of "decide which set of pros and cons to accept". Cheers, ew0k
On Mon, Mar 08, 2021 at 01:38:24PM +0100, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote a message of 34 lines which said: > We need to clarify the spec around what TOFU means for clients and > servers, The issue on this in the specification is #5 <https://gitlab.com/gemini-specification/protocol/-/issues/5>
I have written up how clients and servers can support out-of-band pubkey
verification to add a higher level of trust where needed. My opinion is
that for 99% of connections made by most clients, TOFU provides sufficient
security. For those situations where TOFU is judged by the user to be
insufficiently secure, clients can (sic) offer a variety of different
ways to support easy out-of-band verification.
I call this approach "Trust, but Verify (where appropriate)."
In a nutshell, 3 security levels would be offered and displayed by a
client following this, the first 2 of which are already part of TOFU:
- red: untrusted, mostly if certificate mismatch is encountered
- yellow: trusted, likely the large majority of all connections,
here the host cert matches the known host of the same name
- green: verified - cert matches known host, plus the client has
matched the cert with an out-of-band digest of the cert,
confirming the identity of the server. This would be useful
for connections involving sensitive information.
The details should be left to the client, with some technically simple
examples provided (entering/pasting pubkey hash, random art like
'ssh-keygen -lv'). A variety of technically more complicated ways to
confirm the pubkey like TLSA, DANE, TXT records could fall into this
approach, too, but I think it could be left up to the client and servers
what ways to offer to support the verification.
The full write-up is hosted here:
gemini://thfr.info/gemini/modified-trust-verify.gmi
thfr
mbays <mbays@sdf.org> wrote: > But there's a much simpler version which avoids chains. > If your server is currently using certificate A and you want to switch > to a new certificate: > * create a new self-signed certificate C with key K, > * sign it with A to produce a signed certificate S, > (e.g. using openssl x509 -CA A.crt ...) > * tell your server to use S and K. > > So why don't we make this a convention? Any subtleties I'm missing? The big issue with this is, what if a client misses a certificate update? If the server's first cert is A (self-signed because it has no previous certs), second cert is B (signed with A) and third cert is C (signed with B). If a client connects to the server when it is using A, they will save A, which works fine. But if they then don't connect to the server for a while, and the server now uses C, then there is no direct trust from A to C (unless you provide the entire B cert during the verification, which is just cert chains all over again), and the client cannot verify the server. One solution to this is what I had originally proposed on this thread: get 'trust servers' to periodically check in on servers (either using my original /.pubkey based idea or checking if the server cert is signed with the previous one), and to share lists of verified servers with clients. This /still/ doesn't solve the issue where a server's cert is compromised. ~aravk | ~nothien
On Wed, Mar 10, 2021 at 07:50:32AM +0100, nothien@uber.space wrote: > mbays <mbays@sdf.org> wrote: > > But there's a much simpler version which avoids chains. > > If your server is currently using certificate A and you want to switch > > to a new certificate: > > * create a new self-signed certificate C with key K, > > * sign it with A to produce a signed certificate S, > > (e.g. using openssl x509 -CA A.crt ...) > > * tell your server to use S and K. > > > > So why don't we make this a convention? Any subtleties I'm missing? > > The big issue with this is, what if a client misses a certificate > update? If the server's first cert is A (self-signed because it has no > previous certs), second cert is B (signed with A) and third cert is C > (signed with B). If a client connects to the server when it is using A, > they will save A, which works fine. But if they then don't connect to > the server for a while, and the server now uses C, then there is no > direct trust from A to C (unless you provide the entire B cert during > the verification, which is just cert chains all over again), and the > client cannot verify the server. > OpenSSH has had host key rotation since March 2015. There's a LWN article which describes the strategy, https://lwn.net/Articles/637156/ I believe OpenSSH solves the issue you raise here by sending all its keys to the client. (I'm no expert here. I could be wrong.)
Certificate rotation and management without downtime is a hard problem to get correct in the general sense, and is basically why layered PKI exists at all, so that leaf nodes can change more often than intermediates more often than roots. The easiest way to avoid this problem is to not expose your capsule to the Internet until you've got a real certificate for it, from Let's Encrypt or similar. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, March 10, 2021 10:21 AM, mbays <mbays@sdf.org> wrote: > - Wednesday, 2021-03-10 at 07:50 +0100 - nothien@uber.space nothien@uber.space: > > > mbays mbays@sdf.org wrote: > > > > > - sign it with A to produce a signed certificate S, > > > > > > So why don't we make this a convention? Any subtleties I'm missing? > > > > The big issue with this is, what if a client misses a certificate > > update? > > Yes, this isn't a perfect robust system, and doesn't make sense if you want to rotate certificates frequently. But I'm imagining that rotating would be something you do only very rarely. > > Why would you want to rotate out your current keypair? > > - Advances in cryptography mean you want to switch to a new algorithm. > > - You fear the key might have been compromised. > > - You want to add a wildcard in the CN, e.g. x.y.z -> *.y.z. > > - The certificate is about to expire. > > - Other exceptional circumstances I haven't thought of. > > As long as you set distant expiration dates, it seems reasonable to expect at least a few years between any of these applying. So just having each certificate sign the next seems like it would deal with most situations, and adds no new protocol complexity or traffic costs. >
---