Re: On email and web security

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 31 December 2015 22:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB68D1A9005 for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 14:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vg03qaAya1n for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 14:47:15 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id D3FB51A9004 for <ietf@ietf.org>; Thu, 31 Dec 2015 14:47:14 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 37366203AB for <ietf@ietf.org>; Thu, 31 Dec 2015 17:54:08 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CA24B6379D for <ietf@ietf.org>; Thu, 31 Dec 2015 17:47:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: On email and web security
In-Reply-To: <304F200F-CF0B-4C23-91F9-BFC06C41BDA8@cisco.com>
References: <304F200F-CF0B-4C23-91F9-BFC06C41BDA8@cisco.com>
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: <13594.1451602033@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/f_qx3oxRoPzCJLLCb6aqtEFcdSE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2015 22:47:16 -0000

Fred Baker (fred) <fred@cisco.com> 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@ietf.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.

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@cisco.com> (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@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-