On email and web security

"Fred Baker (fred)" <fred@cisco.com> Wed, 30 December 2015 20:17 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE61ACF24; Wed, 30 Dec 2015 12:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.811
X-Spam-Status: No, score=-111.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uy1yKKS2SrhH; Wed, 30 Dec 2015 12:17:26 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FDB1A88FA; Wed, 30 Dec 2015 12:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4821; q=dns/txt; s=iport; t=1451506646; x=1452716246; h=from:to:cc:subject:date:message-id:mime-version; bh=gch7wMyiQyoyFycNuKz298XJwez4yHHHPIZL74UqgPM=; b=VTUdaogCn86OsScWmJUTgoMqgUGCjL2Jldt4FuUsz10p2sQfFhts3DXS KL2bl2mfTnPMlSoGuwawzuH1KSoPzEojR6tzz1iaBpLqYr4CIGkCe2A5j FnpoXBaULcsKiyt7+WgYh5nu7/PB8j2LlJz1SpZIA1O0LPegoMeO7nlax o=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,502,1444694400"; d="asc'?scan'208";a="222768619"
Received: from rcdn-core-9.cisco.com ([]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Dec 2015 20:17:25 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com []) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tBUKHPDf024633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Dec 2015 20:17:25 GMT
Received: from xch-rcd-013.cisco.com ( by XCH-RCD-012.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Dec 2015 14:17:24 -0600
Received: from xch-rcd-013.cisco.com ([]) by XCH-RCD-013.cisco.com ([]) with mapi id 15.00.1104.009; Wed, 30 Dec 2015 14:17:24 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: Chair Ietf <chair@ietf.org>
Subject: On email and web security
Thread-Topic: On email and web security
Thread-Index: AQHRQz8Yhwpsk1i0P061C0xMiWpUkg==
Date: Wed, 30 Dec 2015 20:17:24 +0000
Message-ID: <304F200F-CF0B-4C23-91F9-BFC06C41BDA8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_B16E3FA9-298B-47A1-94B6-03EF5CEFDBEE"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/7e08Y0_RO7__ieVCGpTOflDagcs>
Cc: "ietf@ietf.org" <ietf@ietf.org>
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: Wed, 30 Dec 2015 20:17:28 -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 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.

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.