On 12/30/2015 05:17 PM, Fred Baker (fred) wrote: > > Your focus on actual deployment is what triggered this note. When the > IETF stated, 2013, that we should seriously consider encrypting > everything, I took an active step to do so. I extracted every email > address I could find from IETF I-Ds and the RFC series, looked them > up in the PGP Key repositories, and added them to mine. I was already > signing email; I then reconfigured my mail client to, any time I sent > an email to someone whose key I knew, encrypt that email. * Even for folks that get to use PGP, they don't take their chances to deliver their public key securely. At the end of the day, strictly speaking, this can be deemed as "placebo security". Printing the signature in business cards helps a lot (and also introduces the problem of business-card "management" :-) ). My other take has been to put the signature in every mail I send (including those to mailing-lists). This is not really "secure", but give you datapoints over time that you really got the key you wanted. * Mobile mail clients are a real hassle for PGP. And in those cases they are not (anyone?), given the current state of mobile phone security, you'd really think twice before putting your private key in your phone. -- this doesn't impact signed email, but does impact encrypted email (e.g., 've had to "get back home" to read encrypted email I had received). > The result has not been what I might have hoped for. > > First, I note that this email is going out unencrypted. Why? I don't > have a key that I can presume every person on this list will be able > to use to decrypt it, and I don't have a key for chair@xxxxxxxx. Yes, > I know those are things our lack of a security architecture has not > sought to fix. There are at least a couple of ways to address it: we > could create a capability for such a key, and we could decrypt > signature-verified emails at the server and re-encrypt to list > members that we have the keys for. I'm sure our security community > can come up with a better answer than either, and I invite them to do > so. My point is that we can't "encrypt everything" if we can't > encrypt email sent to an alias. It's not just about encrypting. In many cases, there's trust involved (whether implicit or explicit). e.g., in your scenario of "decrypt and encrypt" at the server, I should be trusting the server. Is there a reason for that? Yes, that could be thing as "better than nothing".. but at the same time could give a false idea of security and also lead people that the email content is authentic, where it could have been maliciously modified at the server. HTTPS has similar issues (trusting whoever issued the certificate, trusting servers providing the content, etc.) > Second, many of my colleagues have asked me to remove their old keys > from my database, because they have forgotten them, although the PGP > repository has not. It may be necessary to purge the PGP database, > obsoleting and removing keys that have been superseded, and advising > holders of keys that their keys are old and should be updated. I > actually cannot encrypt to the entire set of keys I downloaded, only > those whose holders can still decrypt such communications. In this case, setting the keys to expire at some point when you create them makes sense. > Third, I note that when I receive a signed email that has gone > through an IETF alias, I can no longer verify the signature as a > result of content modification. What is the value of a signature one > cannot verify? I guess this depends on how you're signing. If you do in-line PGP, this shouldn't be an issue. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492