Re: On email and web security

Phillip Hallam-Baker <> Wed, 13 January 2016 02:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2202F1B2BDD for <>; Tue, 12 Jan 2016 18:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGvntCPoleBn for <>; Tue, 12 Jan 2016 18:27:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 939B11B2BC8 for <>; Tue, 12 Jan 2016 18:27:02 -0800 (PST)
Received: by with SMTP id h129so51250864lfh.3 for <>; Tue, 12 Jan 2016 18:27:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g/ebauftZWiuoHL6FB77HI0MOeb4DCE6CjiVYwZ1yG4=; b=SMkn83ybr64kQdUZAuNC4tUaoCIOrhn1HhG9vEDU+Rt7SS8CE1LvOe8ZMEC9L7MC+8 /Vj8qijTqFMm/VrYd1EH+xLxjWDdRblx45YzBy1JiBmHQDaylUxCr4+xLPC0ggBMoPcg ydUt2iiLvaaBEtJE0Fv/MzsEnX9WSHeaJm5IsROahwjdCFcG4WM85VyJQ59fVL5zIblD DwJRbDk1uyilt3radlUwjtm2IZhG/k+gJK5Ya3n66DwwVxVoCATnxu7cfoqjzVGHQAAs SQpgkgjXjJxe5XYTFnkvs1Ltr74gTBXJ16iEhYqvcl1Ez95Wi30v//PiInLyDlluoZAB Eedg==
MIME-Version: 1.0
X-Received: by with SMTP id b73mr33005634lfb.43.1452652020876; Tue, 12 Jan 2016 18:27:00 -0800 (PST)
Received: by with HTTP; Tue, 12 Jan 2016 18:27:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 12 Jan 2016 21:27:00 -0500
X-Google-Sender-Auth: xil3EJ8KmTXakHOhYoTm5oJv3l0
Message-ID: <>
Subject: Re: On email and web security
From: Phillip Hallam-Baker <>
To: Doug Barton <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: IETF Discussion Mailing List <>
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, 13 Jan 2016 02:27:04 -0000

On Tue, Jan 12, 2016 at 8:32 PM, Doug Barton <> wrote:
> On 01/02/2016 09:13 AM, Phillip Hallam-Baker wrote:
>> On Sat, Jan 2, 2016 at 2:25 AM,  <> wrote:
>>> "If Alice wants to encrypt the message for a group of people, she has to
>>> encrypt the message for every member of the group."
>>> really? not encrypt the message to a random key, then encrypt that key
>>> separately to each member? much less processing...
>> That is how it is done under the covers, yes. But that is the sort of
>> optimization that I assume everyone knows.
>> With standard S/MIME or PGP, the final message has a decryption blob
>> for every recipient. So if you are sending to the IETF list, there are
>> three consequences:
>> 1) The sender has to know the entire recipient list
>> 2) Every message sent reveals the entire recipient list
> Not necessarily ... there are ways to encrypt a message without revealing
> the encryption keys that it was encrypted to. They are slightly messier for
> each list member to decrypt if they have multiple keys, but for users who
> only have single keys they are actually quite painless.

Not without modifying the specs and the apps you can't. If you are
going to do that then proxy recryption does exactly what you want.

>> 3) The recipient list cannot be expanded after the message is sent
> That's no worse than current mailing list software.
>> Using the recryption approach, the sender only encrypts the message
>> once, to the key corresponding to the group (or security label if you
>> want to think of it that way). So messages don't disclose anything
>> about the other list members.
>> This isn't just better security, it is a lot easier to implement
>> because senders don't need extraneous information. It is also more
>> manageable because a member added to the list after the fact can read
>> all the messages in the archive.
> Doesn't this require each member to have the group's private key so that
> they can decrypt the messages?

No, each user has their own private key. It is supplied by the group
admin when they subscribed or it is encrypted under their public key
and sent out with each message.

> I thought (but have not verified) that such
> systems decrypt the message with the group's private key, then re-encrypt it
> to the public keys of the list members at that point in time.

That is what my understanding of how it is done today by the systems
out there. What I am saying is that twenty years ago Matt Blaze showed
us a better scheme and nobody seemed to notice the importance at the

> That would mean of course that you would only be able to decrypt messages
> from the time period where you were a member of the list.

If you use the old technology, that is one of the problems. The other
is that you have to find someone you trust to run the mailing list or
the jabber contact service or whatever.