Thanks for your recent blog post at https://www.ietf.org/blog/. One comment you
make that I want to reflect on is that "We need to continue the work on
increasing the security of web and e-mail traffic." I agree that we need to be
more secure.
IMHO, to approach that, we don't want to add yet another random security
capability. The "let a thousand flowers bloom" policy promulgated by Jeff
Schiller (or perhaps his predecessor) has not worked for us. We need a
consistent security architecture that can be readily and simply implemented
using otherwise-current technology.
I would take that a step further; one outcome of a usable security architecture
should be privacy - they are not the same thing, and are also not opposed, but
are two sides of one coin. When security is breached, privacy is breached, as
one might note with the United States Office of Personnel Management (OPM)
breach and the various bits of malware being found that funnel credit card
information to unauthorized parties. When privacy is breached, security often
is as well; a motivated attacker is given a language for password guesswork
that was previously unavailable. Let's not treat them separately; let's solve
those problems together.
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.
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.
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.
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?
In other words, tools tend to work a lot better when they are used. We need to
actually use our tools, not just as individuals, but as an organization, and
where they are not serving us well, we need to correct that.
signature.asc
Description: Message signed with OpenPGP using GPGMail