Re: On email and web security

Kathleen Moriarty <> Wed, 30 December 2015 21:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 114981AD272; Wed, 30 Dec 2015 13:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-lTeEBqZoAS; Wed, 30 Dec 2015 13:27:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD5151AD259; Wed, 30 Dec 2015 13:27:52 -0800 (PST)
Received: by with SMTP id e32so100495320qgf.3; Wed, 30 Dec 2015 13:27:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xTJH2Gc3fExQYN5Zfj//h93FbbkQWGYMR1QU/iZqaro=; b=rIm0JSqCcGNaJdn+y0txcwTWGCBuGuaHY4UMpQtxWFSd0Rmm3JvJ6p40O5FaEYm6E8 9LPWME3brHJvIteAIQqGFxVfBjCeI3P6EVnPWkqqZ3NZGSwf5fbNAEarR/AFhnvDrrcE 1w2BF6Fr5ZTorXuU0uRpmTaA+/sZngu4uDySvtyWI0FiOvzvt1Ghcimi5Pm9Dja5CjA3 5BYd4aFJh2iyDblILzcZfFrnNE7yFOzW3i0dymSRpnwAedGdMmAlGAURTnkiErQ7un3u LVEKL8Fdq4vSXvo4Vltyf89L+ee4S1JEXmsyLqiXIwiC5XcJGK6xGTA36Lv7HsZ+5UvQ IJgA==
X-Received: by with SMTP id o63mr88475111qge.43.1451510872063; Wed, 30 Dec 2015 13:27:52 -0800 (PST)
Received: from ?IPv6:2601:19c:4501:c5b4:c86b:e6e0:96fa:23b4? ([2601:19c:4501:c5b4:c86b:e6e0:96fa:23b4]) by with ESMTPSA id i5sm13014799qhi.18.2015. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Dec 2015 13:27:50 -0800 (PST)
From: Kathleen Moriarty <>
X-Google-Original-From: Kathleen Moriarty <>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: On email and web security
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <>
Date: Wed, 30 Dec 2015 16:27:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Fred Baker (fred)" <>
Archived-At: <>
Cc: Chair Ietf <>, "" <>
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: Wed, 30 Dec 2015 21:27:55 -0000

Hi Fred,

Sent from my iPhone

> On Dec 30, 2015, at 3:17 PM, Fred Baker (fred) <> wrote:
> Thanks for your recent blog post at 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,

I agree completely and noted this as a challenge for next year in terms of improving education on security threats.  From reading lots of drafts, I think a pretty good job was done on pervasive monitoring threats as these are usually covered.  Drafts typically cover privacy, but we do have to help with that in IESG review on occasion. Security threats via active attacks seems to be a gap and we should work on that and provide better education materials and ways to promote awareness.

There are a few talks planned for the routing area, but that's only one step.


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