Hi Fred,
Sent from my iPhone
On Dec 30, 2015, at 3:17 PM, Fred Baker (fred) <fred(_at_)cisco(_dot_)com>
wrote:
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,
I agree completely and noted this as a challenge for next year in terms of
improving education on security threats. From reading lots of drafts, I think
a pretty good job was done on pervasive monitoring threats as these are usually
covered. Drafts typically cover privacy, but we do have to help with that in
IESG review on occasion. Security threats via active attacks seems to be a gap
and we should work on that and provide better education materials and ways to
promote awareness.
There are a few talks planned for the routing area, but that's only one step.
Thanks,
Kathleen
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.