On Sun 2025-11-09 12:49:14 +0000, Frank Seifferth wrote: > I believe that in theory it should be possible to model the behaviour > described in the autocrypt spec as a notmuch query. However, at the very > least, this would require the "first seen" date to be made available in > the notmuch query syntax.
Hm, does notmuch even store that information about each Message-ID or file? > I am also not sure if it would be worth it to follow the autocrypt spec > to the letter. I agree that there's no need to *limit* notmuch to the Autocrypt recommendation algorithm. The Autocrypt spec itself proposes that it is a "recommendation" (not mandatory) [0], and has guidance about diverging from it. [0] https://docs.autocrypt.org/level1.html#provide-a-recommendation-for-message-encryption But if we're talking about a subcommand named "notmuch autocrypt" it'd be nice to make sure that at least that subcommand identifies the the Autocrypt recommendation, even if some other part of a notmuch-based MUA decides to vary from it. Alternatively, we could choose to name it something else :) > Delta Chat recently moved away from the autocrypt spec > to the extend that one could be tempted to argue that they broke their > autocrypt support. My understanding is that Deltachat is moving away from the e-mail address as the primary identifier for a peer contacts, and to the OpenPGP certificate as the primary identifier. So they don't need the Autocrypt recommendation ("for this e-mail address, please give me an OpenPGP certificate and a recommendation about message encryption defaults") at all. Instead, when composing a message in delta, the contacts all already have OpenPGP certificates (by definition) and the default is that every message is encrypted. I don't think a more traditional MUA (such as most of those that involve notmuch) is in the position to make a comparable transition though. Traditional MUAs lean heavily on the e-mail address as peer identifier, and have to deal with cleartext messages (both incoming and outgoing) as well. > the security aspects of autocrypt boil down to something like: "At > least using this key won't be worse privacy than using no key at all." This was actually quite close to the motto of Autocrypt when we were working on it: "Autocrypt: It's probably better than not doing it", so i'm glad that came through! ☺ But the Autocrypt recommendation and peerstate are pretty finely calibrated to work together for an MUA that wants a better-than-nothing answer to that question, intended to not only improve privacy, but also to reduce the risks of footguns like encrypting messages to people who can't decrypt them. If a cryptographic MUA sends an undecryptable message, that's a pretty big papercut. Most users will decide that encrypting mail is too painful and stop using it, or turn off the encryption feature entirely ☹ > I myself started only this year to actually use gpg -- I had previously > heard that it was hard and unpleasant -- and I was very surprised by > what I perceived to be a very straight-forward UX. Obviously, I am only > using a very small subset of gpg. Basically, the only thing I use it for > is importing and listing keys. First, I imported my secret key via what > is now available as > > notmuch autocrypt --import-secret-key > > I then started importing other peoples' keys via one of > > gpg --locate-external-keys EMAIL... > notmuch autocrypt --locate-keys EMAIL... > curl URL | gpg --import > cat FILE | gpg --import > > Finally, I sometimes have a look at my two keyrings via > > gpg --list-secret-keys > gpg --list-keys > > Everything else (i.e. message encryption, signing, decryption, signature > verification) is already handled very well by notmuch and bower (the > notmuch frontend I use). I also entirely ignore the trust level of keys; > and my manual key handling is mostly a mix of TOFU and delegation of > trust to the CA certificate infrastructure of HTTPS requests. But at > least it works(tm) pretty well in practice. What you're describing here i would describe as "stateful OpenPGP" -- and i agree, it *looks* like it works™ pretty well in practice. The rough corners come up in places where the assumptions the various parties sharing the state don't match each other (or don't match the mechanism used to store the state in the first place. For example, if someone can mutate that state in a way that you don't expect, then they might be able to convince you to do things that harm either the privacy or availability of your e-mail. I'll come back to this below, where you talk about input validation. On the flip side, if we can have a reasonable pass at answering the autocrypt recommendation, then we don't need "stateful" OpenPGP at all (we can just use the recommendation directly, in combination with a pointer to the user's own secret key material), and it should be relatively easy to map notmuch and bower into a stateless OpenPGP implementation, of which there are now many. > as long as this tooling is not supported by both notmuch and bower, I > don't see much of a point in supporting it in notmuch-autocrypt. I > also think that it makes sense to prioritize support for a single > setup first, before thinking about supporting additional backends. I think we might be able to have our cake and eat it too. What if we could identify the valid autocrypt recommendation, *and* make it easy to feed it into gpg for those that want that? Making it possible to produce the Autocrypt recommendation should make it easier to move to other OpenPGP implementations. But maybe we need to work on both in parallel. > https://tilde.club/~seifferth/repos/notmuch-autocrypt-old/ thanks, this is super interesting background work as well. I got stalled on this years ago just trying to fit the autocrypt peers table into the notmuch database, so i know the feeling ☹ I like that you've taken a couple different approaches at making this work. > Yes, the security implications of using notmuch-autocrypt in its current > form are pretty daunting. I figured that this might be acceptable for a > rough prototype. But if notmuch-autocrypt sees any real use, we should > definitely add proper input validation -- which would require parsing the > OpenPGP certificate to confirm that it conforms to the subset specified > in the autocrypt spec; and that the OpenPGP certificate actually specifies > the same User ID we would expect from its context. Autocrypt explicitly says that the user ID field in the OpenPGP certificate is "decorative", and is neither required to be present nor matching. But because of the way that GnuPG handles "stateful OpenPGP", the user ID has to match the e-mail address exactly for it to be safe to inject the certificate in the "keyring". Then i suppose we also need to be able to reason about what other inputs might be modifying this shared state, and how (or whether) we update the state if we receive new certificates from a given peer. We also need to be able to identify that newer messages *without* an Autocrypt header have come in from the same sender, so that a peer can safely turn Autocrypt off. > 1. If `notmuch new` would add `tag:autocrypt` to messages that contain > an autocrypt header, I could a) use this tag to make the query for > `notmuch autocrypt --locate-keys` more efficient and b) I could easily > notice that a peer is using autocrypt even if my notmuch frontend knows > nothing of autocrypt semantics. This ought to be a fairly straightforward and achievable task. The only issue is that it might need to trigger a re-indexing (if someone wants to evaluate their old mailstore). But you could also just start indexing new messages and be OK with the fact that you'll only start identifying Autocrypt messages going forward. That's still "probably better than not doing it". Want to try to produce such a patch for notmuch? I'd be happy to collaborate on it. > 2. If `notmuch show` could be used to dump the effective header of an > encrypted message (e.g. inlining protected headers), notmuch-autocrypt > would not need to do this kind of message parsing itself. I like this as well -- what if it produced the per-message output when --format is sexp or json? we could have a simple "autocrypt" label that contains keydata and prefer-encrypt. Doing this fix here would also mean that we could include Autocrypt headers from inside the cryptographic envelope, on an encrypted message. I'd also be happy to collaborate on this. > 3. If notmuch was aware of Autocrypt-Gossip headers, notmuch-autocrypt > could potentially use the key gossip extension to autocrypt to > find even more autocrypt keys. The problem with "Autocrypt-Gossip" > headers is that they can appear in any message (whereas "Autocrypt" > headers for [email protected] should only appear in messages > `from:[email protected]`). If I could query notmuch with something like: > > notmuch search property:[email protected] > > this would allow notmuch-autocrypt to efficiently locate such headers. I like this one too, but i think it maybe we can tackle it once the other two pieces are complete. Then we should try to map out what the new subcommand actually looks like! --dkg
signature.asc
Description: PGP signature
_______________________________________________ notmuch mailing list -- [email protected] To unsubscribe send an email to [email protected]
