Subject: On email and web security

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 30 Dec 2015 20:17:24 +0000

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 [email-masked]. 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.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Dec 2015 15:33:04 -0500 (EST)

> 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 da…

That is one of the motivations behind:

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey

You can also add a milter plugin to sendmail/postfix that will encrypt
automatically for you on outgoing/forwarding email:
https://github.com/letoams/openpgpkey-milter

You can generate openpgpkey records using hash-slinger's openpgp command:
https://github.com/letoams/hash-slinger

> 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 ne…

I agree. When I first enabled openpgpkey-milter myself, I forgot that my
email is delivered to mx.nohats.ca, and forwarded to a private IP that
is my local mailserver at home. So mx.nohats.ca dutyfully encrypted ALL
my email it forwarded. Neither I or my mail tools were ready for that.
I'm hoping mail clients will be able to receive/decrypt a lot more
easilly and store email unencrypted (depending on disk crypto for
privacy) so one does not lose the ability to read/search through old
email)

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 30 Dec 2015 16:27:49 -0500

Hi Fred,

Sent from my iPhone

> On Dec 30, 2015, at 3:17 PM, Fred Baker (fred) <[email-masked]> wrote:
> 
> 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.
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 Dec 2015 18:54:51 -0300

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).

> 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 [email-masked]. 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: IETF Chair <[email-masked]>
Date: Thu, 31 Dec 2015 00:19:09 +0200

Thanks for the comments, Fred, and I agree.

In particular I agree that we need a better and more coherent
security architecture. Not necessarily as a way to cut the other
flowers but as a model of how to do things securely.

And I agree about privacy being an inherent part of security.

And I agree about using our own tools as an organisation, but
with a caveat. When we worked on, say, HTTP/2, we didn’t do
that for the sake of our own website. We did it for the sake
for major content providers and most popular web browsers.
If what we worked on in privacy didn’t work for the IETF or
us individually, it would be very weird. But it also cannot be
the only goal, we have to share minds with major current
or potential users of the technology. What would those be
in the e-mail case, and kinds of things are they likely
to need? Having a good answer to those questions is
probably as important as having all of us turn on particular
forms of security in our individual communications.

(I should probably insert a reminder that even in e-mail
there are actually many subproblems and and aspects.
End-to-end content protection is just one. But both my
discussion above and yours Fred were focused on the
end-to-end part.)

Jari

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2015 19:37:21 -0000

>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.

FWIW, the public repository at pgp.com reverifies the keys from time
to time.  Earlier this week I got a couple of messages saying that if
I still wanted them to publish keys corresponding to those addresses,
click through and reconfirm.  (Yes, I realize how weak this is, but
in the circumstances it's better than nothing.)

Your overall point that the problem with crypto is that it's unusable
if you're not a hard core geek is of course correct.

>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?

With the advent of DMARC, this problem now affects a lot more people
than ones who are looking for PGP signatures.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Dec 2015 17:47:13 -0500

Fred Baker (fred) <[email-masked]> wrote:
    > 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

A noble experiment; one I've done in other contexts, with mostly the same results.

So one of the things that I would like to have in my *MUA* is a queuing (or TCP)
capablity, such that I can enqueue an email to someone that I have not
conversed with at all (or recently).
I might possibly use number of different addresses, and my MUA would
basically ask their MUA how to best contact them, and request their
capablities.
Basically: I want TCP SYN (with options) over RFC2822.
Once my MUA knows how/if to encrypt, then it can send the message.
If I told it to do "OS", then failing to encrypt is okay.  If I demanded
encryption, then it should fail.

Some MUAs now more intelligently associate mailer daemon replies with the
original message, and there is some amount of read-notification available,
but that turns out not to be what I want.

    > 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 [email-masked]. Yes, I
    > know those are things our lack of a security architecture has not
    > 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.

So, I'm not sure that using PGP to encrypt mail for mailing lists which are
publically archived is really meaningful.  I think SMTP layer privacy is more
appropriate.  Signatures: priceless.
But, maybe I'm wrong:  maybe this privacy effort has an anciliary security
value.

    > 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 don't have this experience. Your email verified just fine:
  [[PGP Signed Part:Good signature from 46B200E4BF110F0C Fred Baker
  <[email-masked]> (trust undefined) created at 2015-12-30T15:17:23-0500
  using RSA]]

maybe the problem is closer to you?

    > 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.

Agreed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Jan 2016 00:00:02 -0500

The problem of messaging security right now is very similar to the problem
we had early on with stopping spam. Whenever someone proposed a solution to
problem X, they would be drowned out by a chorus of people saying that the
REAL problem is Y and then someone would insist it is Z and then someone
would demand that the solution work in zero gravity.

There are many problems to be solved with messaging security and I think
they are all solvable *in time*. There are problems that can be solved
right now and there are problems that we can't address for a couple of
years when some critical Intellectual Property is no longer encumbered. And
there are problems that can't be solved without completely re-doing the
messaging infrastructure.

So here is the problem I have been working on recently. At the start of
this thread Fred complained that he has a list of people's PGP keys and
email addresses but can't send them encrypted mail. I have a PGP key on one
of the key servers but I tell people not to use it because I don't have the
private key. I installed a plug in, started the program and it uploaded the
key to a server without asking me and didn't tell me how to delete it
either. And it turns out that isn't possible.

We can't get everyone using encrypted mail if we design products for
outselves, like Fred pointed out. But another part of the problem is that
these days we all have multiple devices and neither OpenPGP nor S/MIME has
any mechanism that is suitable for managing that situation.

No copying my private key file about is not a solution. A private key that
is installed on more than one machine should be rolled over regularly. By
which I mean once a month. So using fingerprints of public application keys
isn't going to be an answer either.

My point here is that the email security apps are not currently usable and
there is no way to make them usable without standards support to automate
the administrative tasks that are dumped onto the user.

Which is what I have been building the Mathematical Mesh (MMM) to address.

I have released the code:
http://sourceforge.net/projects/mathematicalmesh/

Next week I will be working on some demonstrations. The bottom line is that
any time that the user is given a set of instructions to follow, that set
of instructions should be given to the computer instead as code.

The prototype runs on windows and will configure unmodified Windows Live
Mail to use S/MIME without the user needing to do anything other than say
which applications they want to secure.

The same approach can be applied to OpenPGP. But rather more interestingly,
it can be applied to SSH as well and the same tool that simplified
management of cryptographic configuration can be used to simplify network
configuration as well.

PHB