Re: [dane] Improving DANE S/MIME Privacy

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 11 April 2017 17:38 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1482A129584 for <dane@ietfa.amsl.com>; Tue, 11 Apr 2017 10:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 az9x3-UVewPU for <dane@ietfa.amsl.com>; Tue, 11 Apr 2017 10:38:57 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7858C12704A for <dane@ietf.org>; Tue, 11 Apr 2017 10:38:57 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A17167A32F1 for <dane@ietf.org>; Tue, 11 Apr 2017 17:38:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 11 Apr 2017 13:38:55 -0400
References: <f7332bd5-f003-c828-8f4a-0d543099c872@domblogger.net>
To: IETF DANE Mailinglist <dane@ietf.org>
In-Reply-To: <f7332bd5-f003-c828-8f4a-0d543099c872@domblogger.net>
Message-Id: <4BE233BA-D524-4D05-87C5-E898DD646E7C@dukhovni.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/c9PgHK-LTqSMqTsaQnQKhHJnZBo>
Subject: Re: [dane] Improving DANE S/MIME Privacy
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2017 17:38:59 -0000

> On Apr 11, 2017, at 1:16 PM, Alice Wonder <alice@domblogger.net>; wrote:
> 
> 
> One of the things I worry about is spammers discovering valid e-mail addresses
> through the DANE S/MIME and then using the public key of that user to send
> encrypted malware that can not be filtered on the SMTP servers because it
> is hidden.

The simplest solution is to publish only "2 1 1" records in the DNS that
identify the CA that signs the user's certificate, and does not vend the
underlying public key.

Then a first-contact message to any recipient goes in the clear, signed
by the originator, along with the originator's certificate.

The recipient can then respond with an encrypted and signed message that
makes it possible for all further communication to be fully protected.

If the sender is a spammer, the recipient should not respond with a
message that enables further communication to be encrypted.

Note also that the problem you're concerned about already exists with
PGP keyservers, but the authenticity of the data on those servers has
much lower assurance.  DANE SMIMEA records are largely an improvement
on the PGP keyserver model.

If the design were up to me, I'd not have published per-user keys.
Instead a site-wide trust-anchor record scales better to large user
communities, and mostly addresses your concerns.

Of course user keys can leak by various means (posting signed messages
to a list, replying to a spammer, ...).  Preventing that entirely seems
impossible, but policy mechanisms in the MUA could make accidential
leakage less likely (e.g. not signing messages that are not addressed
to someone in the user's "address book", so a conscious manual step
would need to be taken to leak a public key that enables encryption in
the reverse direction).

Today's MUAs support End-to-End email encryption very poorly.  Much
usability work needs to happen before End-to-End email encryption
is more than a curiosity.

-- 
	Viktor.