Re: On email and web security

Dave Cridland <dave@cridland.net> Wed, 13 January 2016 08:23 UTC

Return-Path: <dave@cridland.net>
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 962F41AC3C3 for <ietf@ietfa.amsl.com>; Wed, 13 Jan 2016 00:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.822
X-Spam-Level: **
X-Spam-Status: No, score=2.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=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 YCwILUW3YWFN for <ietf@ietfa.amsl.com>; Wed, 13 Jan 2016 00:23:07 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 B1D6E1AC3C1 for <ietf@ietf.org>; Wed, 13 Jan 2016 00:23:06 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id u188so287072008wmu.1 for <ietf@ietf.org>; Wed, 13 Jan 2016 00:23:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=psOX6yOVW5GtltfdMItVlVMahbREw2cmY5FV9KSRhDs=; b=SsKBP9//opuHPCxe5wb2RmasYzQrndmWbIqbJyibSEsrCagRGbxMz6hgQZK5rdWEzy b8Tzm0gXHs2BXXKi6RnQNp4yskDsqMZBNS9YQqkQeGrcjp2sfwUwLsxizRoVuVnkZmsl ny/z25DGvLMVIEKJwVEi02GU7xKzSl8eG/BCk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=psOX6yOVW5GtltfdMItVlVMahbREw2cmY5FV9KSRhDs=; b=ZRp0Qqmwk8MPaqYjrlHLe6Q0GgyoHUXYZk5XiOG11uRjEh5oRckgraKhkh4yFvRwlB +TCb2I/7u9hjo8NDSm1gDuKkXeQDFoLCGPqwC182u7hsCnSDOGBBy8/V8lnMn4es67zF tMrHDI4O70658K27zRvcmQ3qB0V72FRoxd4EVKmMdLkDb7ZDRXHZqlCvfhrfhz5XV+GY B2csm7NNUumdLCcJBkxwBq3nTcaj8sqzpXLBd5YbhkzAu/1v6NRyluiHg6AbaC9M5glQ PJx90A/MVOhaFL2cHz0D7ZTgaD4EAPdkZ1E1uvrDJKAX2pSULgW5wCuLGeY2qO44f3KQ wzzA==
X-Gm-Message-State: ALoCoQnBdhDow7WgniCM7dPJfMS5rfmzCz9PEKP/SF0YtKwz9WTZfW6mVLnzaF8WfcF4LdORmJF6wdbSx92TvQFXc/x1ylRx3kOrw+3AT9nmuuK/FQq2c08=
MIME-Version: 1.0
X-Received: by 10.194.216.100 with SMTP id op4mr124254792wjc.85.1452673385182; Wed, 13 Jan 2016 00:23:05 -0800 (PST)
Received: by 10.28.47.84 with HTTP; Wed, 13 Jan 2016 00:23:05 -0800 (PST)
In-Reply-To: <5695EFC1.7070708@dougbarton.us>
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> <CAMm+Lwh_6EP4d4tW8CgKZm36De7rO3VCbrBwa+1PGp9M2F4KLQ@mail.gmail.com> <5695A941.1010501@dougbarton.us> <CAMm+LwiJi+ecYU9edkTJ30rTWtRcarUD2BBYfyvRedRvVzcV5Q@mail.gmail.com> <5695EFC1.7070708@dougbarton.us>
Date: Wed, 13 Jan 2016 08:23:05 +0000
Message-ID: <CAKHUCzzxO7V=zipoQR1a_-Sy4AuY6ie7hCa55fd0aaj_BTURXg@mail.gmail.com>
Subject: Re: On email and web security
From: Dave Cridland <dave@cridland.net>
To: Doug Barton <dougb@dougbarton.us>
Content-Type: multipart/alternative; boundary="089e014935f4195478052932e15e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/NS-btf76zh0-x_Vfqfw3IXD8iLg>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, "ietf@ietf.org Discussion" <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, 13 Jan 2016 08:23:08 -0000

On 13 Jan 2016 06:33, "Doug Barton" <dougb@dougbarton.us> wrote:
> Well that's a given no matter what solution you choose. If you're relying
on someone else to do encryption on your behalf, you have to trust them.
But that's a marginal increase in trust compared to running a non-encrypted
list in the first place.
>

If I understand proxy re-encryption correctly - and I almost certainly do
not - then there are four roles. It'd be really useful to be shot down on
any misunderstandings here. Note that I have no clue how the maths works,
and have therefore attributed this to the crypto-fairies.

The sender, who has the private keys for themselves, and the public key of
the proxy.

The proxy, which has the recryption keys of the members.

The members, who each have their own private keys.

The administrator, who has magic fairy dust allowing new keys to be added
as members of the proxy.

When senders send to the proxy, they're encrypting in a special way which
means that the proxy can't decrypt; instead it can only re-key the message
to each member. The proxy also cannot add other keys (including its own),
so cannot just add itself as a member and decrypt the result. Members
receive the message, and thanks to the crypto-fairies, they see it as
signed by the sender. I like to think of this as a special-case of
homomorphic encryption, but only so I can sound like I know what I'm
talking about.

Members provide their public key to the administrator on joining; the
administrator then applies magic fairy dust to provide the proxy with a
recryption key specific to that member.

Reading Phillip's message, it seems that last bit may be wrong - perhaps
each member gets a key pair from the administrator. That would be rather
disappointing, since it requires the administrator to be much more trusted
than I'd hoped for. If I understand the literature correctly, though, the
proxy never has access to the private key.

I suspect that while Phillip is using the mailing list case to explain it,
proxy recryption is a much better fit when the members are your devices,
the administrator is you, and the proxy is your account-proxy in XMPP, or
your IMAP server (perhaps) in mail. The limitations of administrators
having to provide keys become much more manageable then.

For those not blessed with XMPP knowledge, the bare jid - user@example.com
- is actually hosted on the server and can trivially see every message;
each connected device has a full-jid, user@example.com/resource, so the
bare jid would be the recryption proxy and everything works out very neatly
with the existing model.

> Doug
>