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(_at_)ietf(_dot_)org.
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(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492