On Fri, Dec 22, 2017 at 11:30 AM, Vincent Breitmoser <look@my.amazin.horse> wrote: > > 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
That motivation makes sense (handling encrypted replies to multiple recipients, if you didn't previously have the key of those recipients). But the gossip mechanism isn't aware of replies, it accepts gossiped keys from anyone. Example: A group of users are in an email thread. They are all able to send encrypted replies to each other, because all keys have been gossiped within the thread. Now a malicious user OUTSIDE the group sends a message to a user INSIDE the group, gossiping incorrect keys for the group users. The recipient of this message will accept and use the incorrect gossiped keys for group replies, thus sending unreadable messages. --- Stepping back, I'd worry about the "available" and "discourage" states confusing users. In particular, "discourage" will appear due to different and hard-to-understand reasons, and will sometimes get overridden (in encrypted replies), so sometimes Autocrypt will want to automatically encrypt to a "discourage" recipient and sometimes not, depending on the reply context and gossip history. The simplest design would have Autocrypt automatically encrypt if it's received a recent Autocrypt header from all recipients, with no concept of replies, "prefer-encrypt" policies, or gossip. I'm unsure these add enough value to justify the UI complexity. >> 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 both devices are present, I'm not sure why a roundtrip is that hard, or why you couldn't just enter (or scan) a public key from the recipient device into the source device, before sending the setup message. At minimum you'll need to advise users to be very careful with the secret code, since there's a fragile combination of design choices here (no forward secrecy; user-visible secret "code" that decrypts the private key). >> (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. It seems like striving for backwards-compatibility here makes the design significantly worse (adding several KB to every message would be a real cost if this was deployed at large scale, and on mobile devices). I'm not even sure how much backwards compatibility you're achieving? If you want to support the existing PGP userbase, don't lots of PGP users have keys which aren't 2048 or 3072 RSA, thus couldn't use Autocrypt? If the concern is compatibility with existing libraries like libgcrypt, I'd question the motivation, since there are plenty of (probably better) crypto libraries. Trevor _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
