Re: On email and web security

Michael Richardson <> Thu, 31 December 2015 22:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BB68D1A9005 for <>; Thu, 31 Dec 2015 14:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2vg03qaAya1n for <>; Thu, 31 Dec 2015 14:47:15 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3FB51A9004 for <>; Thu, 31 Dec 2015 14:47:14 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 37366203AB for <>; Thu, 31 Dec 2015 17:54:08 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id CA24B6379D for <>; Thu, 31 Dec 2015 17:47:13 -0500 (EST)
From: Michael Richardson <>
To: "" <>
Subject: Re: On email and web security
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 31 Dec 2015 17:47:13 -0500
Message-ID: <>
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Dec 2015 22:47:16 -0000

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.

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

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


Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-