Re: On email and web security

[Michael Richardson <[e-mail]>]

Fred Baker (fred) <[e-mail]> 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.

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.

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

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
  <[e-mail]> (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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-