On email and web security

["Fred Baker (fred)" <[e-mail]>]

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 [e-mail]. 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.