* on the Thu, Oct 17, 2013 at 05:15:47PM +0200, Jan Kundr?t wrote: > Hi Mike, thanks for a long and detailed mail with plenty of valuable > suggestions. I have a couple of comments and questions to some of them. > >> 1.) Support both PGP/MIME and also Inline PGP for both incoming >> and outgoing mail > > It's 2013 already. The specification for PGP/MIME has been around since > 1996 (RFC 2015, since updated by 3156). What is the reason on why would > anyone bother with inline signatures today?
I also wish Inline PGP would die. The trouble is, other people still use it and I want to be able to decrypt and verify their emails. A feature to compose using Inline PGP is less important than one to read it though yes. > It might be interesting to produce the messages like this, however: > > 1 multipart/alternative > 1.1 text/plain for outlook > 1.2 multipart/signed > 1.2.1 text/plain > 1.2.2 the signature > > Do you happen to know whether this works? Is the state of "work/doesn't > work in OE" depending on the order of 1.1 and 1.2? What's the OE's market > share today, i.e. do we have to cater for it at all? God only knows. I've never used Outlook Express and I don't think it's worth catering for any more. I'm a web developer and I certainly don't cater for IE6 anymore. I imagine having a multipart/alternative at the root rather than a multipart/signed or multipart/encrypted will stop PGP working with proper email clients though. >> 3.) When composing a message, if a Draft is going to be saved >> in an IMAP folder. > > Note that Trojita does not support drafts stored in an IMAP folder yet :). Ah, I didn't know this; It's been a while since I played with Trojita. I've been waiting for somebody to announce develpment of PGP support first ;) >> 4.) When sending an email to somebody who doesn't have a PGP key, we >> can't encrypt. This is less than ideal, from a privacy perspective. >> However, that doesn't mean we also have to save the "Sent Items" >> version unencrypted. An option to encrypt anything that gets added to >> the "Sent Items" folder with the users own public key, would be great. > > This unfortunately completely breaks any efficient sending method like > BURL. I'm not familiar with BURL. I was suggesting the encrypted Sent Items as an optional feature, so they could still both operate along side each other couldn't they? If the user wants encrypted Sent Items, and they've sent an unencrypted mail, then use IMAP APPEND, otherwise fall back to using BURL. >> 5.) An option for making Trojita automatically and transparently replace >> any unencrypted email on the server with an encrypted version. > > I don't think this is a job for a MUA. If you do not trust your IMAP > server, an after-fact opportunistic encryption wouldn't help you anyway. > Even if you are willing to accept that risk, I would suggest simply running > a separate agent responsible for this transformation. You might want to > write one based on Trojita, sure. > > Also keep in mind that this approach has rather wide ranging implications > on efficiency, in particular on any server-side operation. Trojita relies > on these a lot, and will happily use them more in future. You might or > might not get some increased level of security, but you'll definitely get a > slowdown in the speed of operation, pay the price of higher latency and > consumer more bandwidth. I'm sure you know this, but it's good to make sure > people are aware of the drawbacks before they jump into the "let's encrypt > everything" stage. I'll agree that it *should* be done server side if anywhere. Client side is the second best option. However, I'll admit that I never expected you to agree to this one. I thought I'd throw it in there just in case. >> 9.) A warning if we try to send an unencrypted email in response to an >> encrypted email. And *also* a warning if we receive an unencrypted >> email that was in reply to an encrypted email, so we notice if >> some information we didn't expect to be leaked was leaked. > > Now this is clearly interesting from the user's point of view. However, how > do you propose to track this relation, technically? Where shall Trojita > keep the mapping about mails and responses to them? I'm of course aware of > Message-Id/In-Reply-To/References, but this index maintenance cannot be > offloaded to the server anymore (you don't trust it after all), which means > a TON of transferred data. Confused at what the problem is here. Trojita has a "Show Messages in Threads" option, so it clearly knows which messages are in reply to which other messages. When composing a message or viewing a message Trojita should be able to see if it is in reply to another message and therefore should know if that other message was encrypted? Perhaps you mean, if the other message was deleted? The feature could be opportunistic: If Trojita knows that there is a problem, warn about it. If it doesn't, don't. >> 10.) Don't restrict encrypting ability to the UIDs in the key. For >> example this email will be sent from troj...@lists.grepular.com, but >> will be signed using a key which doesn't have a >> troj...@lists.grepular.com UID > I was under impression that the signer identity is checked against the From > header, not against the actual sender. Note that the ML messages are From: > you, not From: trojita-ml, so there is no issue here AFAIK. Not sure if you misunderstood me here. The email I sent had a "From" header of "troj...@lists.grepular.com" which is my own email address (not the lists), yet my public key has no knowledge of "troj...@lists.grepular.com", and that is perfectly valid. I just want to make sure you don't add such a restriction. Also, if you want to send an email to troj...@lists.grepular.com and have my public key, there is no way for your email client to know that troj...@lists.grepular.com corresponds to that public key, as it doesn't contain that UID. However, that shouldn't stop you from being able to manually select the key, and for Trojita to "remember" the connection. Technically I guess, Trojita could see that this very email I am writing now is signed with a particular public key and came from an address that doesn't exist within that public keys UID list, and remember that connection. >> 12.) If there is a photo attached to a public key, display it within the >> trojita GUI, along with the message. > > Plenty of arguments against this on the net center around an argument that > this feature provides a false sense of security. I don't have much of an > opinion here. > >> 13.) Take advantage of PKA records. For example, you can automatically >> look up what the corresponding PGP key for my personal email >> address is without talking to any key servers: > > How is this supposed to be integrated with DNSSEC? How do I validate the > DNSSEC responses from a Qt application? It doesn't rely on DNSSEC. It's as secure as performing automatic key fetches from a key server. It would still require fingerprint validation. However, if DNSSEC is available, (as it is for grepular.com), and you are able to confirm that it passed validation (because you trust your resolver and it set the AD bit), then that does demonstrate *some* level of additional verification which might be worth displaying to the user. >> 14.) Support PGP at any layer of MIME depth. For example, you might have >> an ascii armored inline pgp signed message that is an attachment >> within a PGP/MIME encrypted email. You might also have a single part >> email which contains some unencrypted and unsigned text, followed by >> some ascii armored signed or encrypted text, followed by some other >> non encrypted/signed text. > > You will actually get this one for free due to the way how Trojita's MIME > rendering works. Cool. Then just make sure it handles the case where different keys are used to sign/encrypt different parts of an email ;) -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4
signature.asc
Description: Digital signature
