Fred Baker (fred) <fred@xxxxxxxxx> 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 chair@xxxxxxxx. 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
<fred@xxxxxxxxx> (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 <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature