💾 Archived View for thfr.info › gemini › modified-trust-verify.gmi captured on 2022-01-08 at 13:36:59. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Trust and Verification for Gemini

A Proposal for an Enhanced Security Model for Gemini

Date: 2021-03-08

Author: thfr

TL;DR at the bottom of the document.

Background

Gemini is a new internet protocol that has seen increasing attention in 2020-2021. Besides the relative minimalism compared to the Web, the main other argument that it has going for it is that privacy/cryptography are included (and mandated) from inception:

"[Gemini] takes user privacy very seriously"

This is reflected in mandatory TLS version 1.2 (or higher) for all transactions (see section "4 TLS" in the specification). Gemini rejects the Certificate Authority(CA)-based approach of the Web. Instead, the current state of the specification (which is approaching finalization) advocates TOFU ("Trust On First Use").

There are good reasons to choose TOFU over CAs:

TOFU is lightweight, compared to the CA model. As text/gemini consists only of markup text without pictures or script code, the size of transfers is small, and the bandwidth needs of the CA model would be outsized compared to the content.
TOFU fits the "one document, one connection, one request" philosophy of Gemini. The certificate is compared to the prior certificate (stored by the client); no other connections or authorities are needed.
Once a host is known to the client, TOFU provides reassurance that successful connections are made with the same client, and the encrypted nature of the connection provides protection from eavesdropping on the connection.

Checks involved in the CA model are costly.

Gemini prides itself of simplicity, such that a client can be "a feasible weekend programming project." TOFU strikes a reasonable balance between privacy of the connection and implementation simplicity.

The CA model is not invulnerable to compromise.

Despite these arguments, there continue to be voices critical of the TOFU approach.

Expiring certificates are considered problematic.
Concern about lack of protection of the first connection.
Certificate changes are ambiguous. Most likely they will represent mere expiration/renewal on the server, but could also represent the host being impersonated by an attacker.

This leads to alarm fatigue and "blindly trusting."

For this reason, Drew DeVault recommends long lifetime for certificates (see link to his TOFU recommendations below). This opens up issues regarding the compromise of the private key by an attacker, and the lack of options to revoke a cert.

TLSA/DANE have been proposed, but from my understanding would add more connections and violate the goal simplicity and single connections per document.

TXT records complicate the server setup additionally.

The Problem

To address this problem, I will first attempt a higher level summary:

It should be recognized that the threat model varies...

by person (location, country, usage of the resources)
by Gemini page (reading simple blogs about recipes vs. pages with personal data and password authentication)

For many users, 99% of the pages they visit will be sufficiently protected by what TOFU offers - protection from eavesdropping, and some protection from an impersonating attacker _after_ the first connection to the server. But there are those pages, like for me my bank's login, where this would not be enough protection for me.

Therefore, I would argue for additional flexibility beyond "just TOFU".

One of the key comments in my reading that I agree with:

There seems to be this idea among client/browser developers that a certificate can be validated in and of itself, without out of band verification. This is a mistake [...]

Followed by another one that I will qualify:

We have no out of band way to verify [the fields of the certificate and the certificate itself] anyway.

(both quotes from this resource)

I would qualify this as follows: We have no out of band way to BULK verify ALL CONNECTIONS.

The logical question that has been insufficiently discussed in my opinion is therefore:

"How do you facilitate out-of-band verification IN THE SITUATIONS WHEN IT MATTERS?"

The OMEMO/Conversations Approach that Takes Out-of-Band Verification into Account

Thinking about the issue and reading about related topics, I came across a discussion of the approach of the OMEMO encryption. One criticism leveraged by OMEMO against TOFU is that the problem of manual trust decision is not appropriately resolved (and I would even argue that it isn't receiving any assistance).

TOFU seems to have a tendency to downgrade to the "Trust-Everything approach," as seen with the messaging apps Signal and WhatsApp (described in the following link), as well as simplification proposals for Gemini (in various links and emails).

The way that OMEMO/Conversations address this is with a concept they call "Blind Trust Before Verification." It combines the ease of trusting many devices (thereby avoiding warning fatigue) with the option to verify the fingerprint with hex string or QR code (often after initial use).

Of course, the use and threat model of a messaging app differ significantly from gemini browsers. Compared to messaging apps, use of a gemini browser can be expected to...

involve less data/content coming from the (client) user,
more rarely include intimate or profane content,
manage a greater diversity of content on the spectrum from very generic (daily news) to very personal.

Discussion of the OMEMO/Conversations approach

OMEMO encryption specification

My Proposal - "Trust, but Verify (where appropriate)"

Based on this, I propose a three-tiered system with the following states that could for example be signaled with traffic signal colors:

UNTRUSTED (red): The server fingerprint does NOT match the stored value. User can decide to trust the new cert if the user decides to assume that no malicious reason is behind the mismatch, like a scheduled certificate rotation (servers should still be discouraged from doing this frequently). Decisions to temporarily trust such a certificate (see Drew DeVault's write-up above) could retain the red color/UNTRUSTED marker, as opposed to a decision to permanently trust.

TRUSTED (yellow): The server fingerprint matches the stored one, including after just accepting and storing a new certificate. The user has not verified the cert out of band. For most users, this would represent the bulk of the connections. However, this may not be sufficient for some scenarios.

VERIFIED (green): The fingerprint has been verified out-of-band by the client. This confirms that the server is the one it claims to be. This would be most suitable for sensitive communications.

One advantage of this is that no client would need to be rewritten. The existing TOFU approach already covers TRUSTED and UNTRUSTED scenarios. But clients could be incentivized to assist with out-of-band verification.

Out-of-band verification can be facilitated by the client and server operator as follows:

Clients would be encouraged to clearly display the trust-tier, for example with the above "traffic lights" colors.
Clients could allow entering fingerprints for domains to verify (SHA-256 etc.).
Random Art like 'ssh-keygen -lv ...' can be a quick way to verify visually.

Random Art examples

For some clients, esp. mobile, QR codes may be feasible.
Other more technologically sophisticated approaches like DANE etc could fall under this category, but should maybe not be the only approach for reasons discussed/linked above.
Server operators could be encouraged to share hex/Random Art/QR fingerprints via other channels (social media, http, conferences), especially if they operate with sensitive data (e.g. individual passwords).

Response Status Code 11 - SENSITIVE INPUT

Clients could restrict resources that return status code 11 to VERIFIED (green), or display additional (non-blocking?) warnings if accessing at only TRUSTED (yellow) level.

TL;DR

Gemini's current TOFU model for transaction protection has significant advantages, especially as it provides protection from eavesdropping and server impersonation after the first connection while keeping a low footprint. This document outlines how a system encouraging out-of-band verification of the server fingerprint can increase security where desired, while avoiding the technical burden and pitfalls of a Certificate Authority model.