Hey Trevor, thanks for your feedback!
> (1) The "discourage" UI recommendation seems confusing: > * It conflates two different cases (the recipient's key was last > seen a while ago; the recipient's key was received via the unreliable > "gossip" method). I see your point. I think we didn't want to have too fine granularity for these states, to keep the intention clear. The difference is mostly in "why" something is happening, but not "what" is happening, i.e. it will be a similar UI flow but maybe with different messages displayed to the user. (see below for more thoughts on gossip) > * If it's a bad idea to use this key, I'm not sure why you'd give > the user the option to do so. This is a tough one in terms of UX. If a key worked yesterday, straight up disallowing the user to use it today might be irritating. It's very unlikely the user will go through a (social) roundtrip to get a fresh key, or just not send the message. This leads to a tradeoff between sending plaintext, and risk of unreadable mail. > * The "discourage" recommendation gets overridden in the case that > you're responding to an encrypted message to a group of recipients. > Since this case doesn't change the fact that the key is old or was > received via gossip, I'm not sure why it's OK to override "discourage" > and use the key here. The main purpose of gossip is to ensure that replies to encrypted emails are always possible, regardless of recipients and previously known keys. It's a very common situation currently that a first mail to a group of people is encrypted, and the first reply drops to plaintext because of missing public keys (this happened multiple times even in our own working group!). In a reply, the responsibility kind of chains back to the first sender - using the same key that was used in the message being replied to optimizes for consistency. A scenario that actually gave us a hard time is replying to an encrypted message, when the gossip key from that message differs from a (non-stale) one we have locally. Do we encrypt to the gossip key? Or the one we have? One of these choices will likely lead to unreadable mail, either consistent with the original message, or consistent with other encrypted messages sent to that recipient. The thought to include a freshness criteria in gossip headers to improve this situation was dropped because it leaks just too much metadata. This is one of the places where we hope to offer better answers in the future from experience after rollout. > There are safer possibilities for synchronizing private keys, such as > encrypting to a public key from the recipient device, or using a > "short authentication string" to authenticate a DH exchange between > the source and recipient devices. We're aware, and we thought through these options. However, anything SAS (or generally DH) based requires a communication roundtrip between clients, and that is actually really hard to do between MUAs. If you have a good idea how to do this unilaterally, we'd be all ears. It was important to us that clients have *some* well-defined method of transferring secret keys, to avoid lock-in of generated secret keys. But the complexity we can actually afford is just really low. We feared that if we have a complicated method of transfer, clients might simply omit it, reducing coherency of the ecosystem and user experience. In the worst case they'll offer to just export to file, in which case the chance of those keys ending up in the cloud is extremely high (particularly on mobile clients). > (4) It looks like every message sent by an Autocrypt-supporting mail > client will contain >2 KB to advertise the sender's keys (two RSA-3072 > public keys, two signatures). If you're sending to multiple > recipients and you know some of them support Autocrypt, there will be > an additional >2 KB for each such recipient to "gossip" their info. That's correct, and we are of course aware of the dramatic gains in size from using ECC keys. But so far, OpenPGP implementations kind of aren't there yet :( Once they are, we'll be happy to upgrade. Until then, we decided that something like 10kb are an overhead we're willing to accept. > (5) It's not clear what the "self signature" from master key over the > user id accomplishes. It achieves compliance with the OpenPGP spec and gnupg de facto standard :) We actually considered 1) simply breaking the OpenPGP spec and drop this packet or even user ids entirely, or 2) just going with something else ("25519 in json") entirely. But legacy is important. We want to pick up people where they are, by providing relief from known pain points (e.g. manual key search and group reply) while allowing them to stick to their toolchain, get a foot on the ground and then work from there. From the autocrypt perspective, User IDs are purely decorative, and we really don't have a good idea what to put in there (address? UUIDs? fixed string?), so we decided to stick to a way that is compatible with existing software, e.g. `gpg --list-public-keys user@domain.example`. That said, onboarding for new users should ideally be as free of this baggage as possible. Thanks again for your feedback :) - V _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging