Re: On email and web security

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 02 January 2016 17:13 UTC

Return-Path: <hallam@gmail.com>
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 D27271A1A4B for <ietf@ietfa.amsl.com>; Sat, 2 Jan 2016 09:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level:
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEnurB_ePdZn for <ietf@ietfa.amsl.com>; Sat, 2 Jan 2016 09:13:05 -0800 (PST)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854731A1A51 for <ietf@ietf.org>; Sat, 2 Jan 2016 09:13:05 -0800 (PST)
Received: by mail-lb0-x235.google.com with SMTP id pv2so157779194lbb.1 for <ietf@ietf.org>; Sat, 02 Jan 2016 09:13:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dibrZ94qKXAsQXZFGi6vavsvNVy142/VWB7gPGb9/zI=; b=uK4S1Ibxl5PuRioOQHEcOsUoVfm2IQ9GBZ4SwCVrJzQYWvM5M9XqFHbR//XEtnRZef apGFD03MBzIu6h/MZfiVarPMAuW+vs83aCntM0zkDDTjTgRCw/I4cfz156Kl3jcwTZ9v GieBqQVrxk0iX065s4gC3Xcn8bdQV/jbNcabXNQQnT7ujD3QXUHgMX4rWGn7zsxi8Qnv cSkZIjzeygJ35uUcrXrbsKGW2nlBdp/dxtnM6c9/5fVyRG7V2zNo+rcNBdI+wcpKQMob 3VZMrmRPkuKkxdFfABARLlgBlcByTBUckx3NEMcVyFzBxeBk+KjrO6vu4KDjbWWsKcBK bEUw==
MIME-Version: 1.0
X-Received: by 10.112.54.193 with SMTP id l1mr27490262lbp.58.1451754783774; Sat, 02 Jan 2016 09:13:03 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.1.33 with HTTP; Sat, 2 Jan 2016 09:13:03 -0800 (PST)
In-Reply-To: <DB4PR06MB4571A77D35C4B525CE73398ADF00@DB4PR06MB457.eurprd06.prod.outlook.com>
References: <304F200F-CF0B-4C23-91F9-BFC06C41BDA8@cisco.com> <5686E386.70008@gmail.com> <CAMm+LwhExTXC6xWDbR0Q5owi45UfBAgR+Z96p4BJWi-_5Q5tXA@mail.gmail.com> <DB4PR06MB4571A77D35C4B525CE73398ADF00@DB4PR06MB457.eurprd06.prod.outlook.com>
Date: Sat, 02 Jan 2016 12:13:03 -0500
X-Google-Sender-Auth: x3D1qgm_q7ZTPk68lrnIGnyZptY
Message-ID: <CAMm+Lwh_6EP4d4tW8CgKZm36De7rO3VCbrBwa+1PGp9M2F4KLQ@mail.gmail.com>
Subject: Re: On email and web security
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: l.wood@surrey.ac.uk
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/lMGwBNmdRDlXwrfNv5L2Ck4yraA>
Cc: Doug Royer <douglasroyer@gmail.com>, IETF Discussion Mailing List <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: Sat, 02 Jan 2016 17:13:07 -0000

On Sat, Jan 2, 2016 at 2:25 AM,  <l.wood@surrey.ac.uk> 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
3) The recipient list cannot be expanded after the message is sent

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.


This really is the way to do Content Rights Management and we should
use it to lock down every word processor and spreadsheet document.
Imagine being able to configure your information environment so hat
all your files are encrypted by default but you have access to them
from any machine you configured for access in the past or add in the
future.