Re: [Endymail] We're not done yet
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 17 November 2014 06:39 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2691A0144 for <endymail@ietfa.amsl.com>; Sun, 16 Nov 2014 22:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 roSHp6aWP02z for <endymail@ietfa.amsl.com>; Sun, 16 Nov 2014 22:39:50 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96B91A0137 for <endymail@ietf.org>; Sun, 16 Nov 2014 22:39:50 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EAB99284B0F; Mon, 17 Nov 2014 06:39:48 +0000 (UTC)
Date: Mon, 17 Nov 2014 06:39:48 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: endymail@ietf.org
Message-ID: <20141117063948.GX13179@mournblade.imrryr.org>
References: <CACsn0ck-bueehMDjgx-Co=bL0pLkeJM=Fqc0T_SDT4bdX4nzPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACsn0ck-bueehMDjgx-Co=bL0pLkeJM=Fqc0T_SDT4bdX4nzPg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/7fmM3h4_9OghKDwtYHnKlhfd7oQ
Subject: Re: [Endymail] We're not done yet
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: endymail@ietf.org
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 06:39:53 -0000
On Sun, Nov 16, 2014 at 09:27:58PM -0800, Watson Ladd wrote: > So if I could summarize the problems they are: > > 1: keys are hard > 2: spam is hard > 3: discovery is hard. > > UI work is needed for 1. 2 I have no idea. 3 seems to have some good > ideas floating around to solve it. Of course, in an ideal world we > would get perfect secrecy, but that's much harder, although methods > are floating around to do it. So at least in terms of keys and discovery, the DANE-specific obstacles as are I see them (feel free to contribute to the Dec 02 DANE WG interim): 1. Mapping user addresses onto DNS: a. Email addresses use an alphabet more extensive than DNS labels. b. Email address localparts can (infrequently) be longer than DNS labels, and base32 or similar encodings make the problem worse. c. Email addresses are often, but not always case insensitive. d. DNS names are case insensitive. e. There are for better or worse significant concerns around directory harvesting (even with NSEC3). f. Some folks want key lookups to work with DNAMEs, with the keys published just once and automatically functional for all domain name variants. The current draft proposal lookup keys are base32 encoding of SHA2-254 hashes of the just the user address localparts. This addresses a/b/f and very marginally e. However, the conflict between c and d is rather severe. Key lookups will only succeed when the email address query is for the canonical capitalization of the email address. If the email address were something like: First.Last@example.com and the destination domain supported case-insensitive delivery (e.g. via LDAP in which addresses are not case-sensitive), one might publish the same keys for each of: First.Last@example.com first.last@example.com FIRST.LAST@example.com and hope that these combinations cover all the likely variants. 2. Revocation, or where does one attach the horse to the motor car? http://www.psmag.com/blogs/time-machine/electric-hybrid-cars-cyclists-pedestrians-traffic-safety-52337/ - DANE is an online system for publishing fresh key material. - Ideally revocation in DANE is a matter of just removing the relevant records from DNS, and publishing only those keys are valid at the present time (modulo TTLs and ideally short RRsig lifetimes). - Since X.509 PKI certificates (OCSP notwithstanding) are typically long-term offline attestations, carrying over the web PKI "revocation" compensating measure is not necessarily a good idea for DANE. - Furthermore, in current mail client S/MIME implementations there is no semantically sound treatment of revoked or expired certificates. Mail that arrives today should indeed avoid no longer applicable keys (whether revoked or simply no longer published). However mail that arrived while the key was still valid and was successfully verified at the time, should generally remain valid even if the key is (sufficiently) later withdrawn. - So we are still talking past each other with completely different models and associated requirements, some want to put the horse before the cart, others say the cart is a motor car. - There needs to be a life-cycle model of key management in a world where today's keys are published online, that defines not only how the current keys are located, but how saved mail is handled and whether any sort of "revocation" is required, or whether de-publication is sufficient. -- Viktor.
- Re: [Endymail] We're not done yet Viktor Dukhovni
- [Endymail] We're not done yet Watson Ladd
- Re: [Endymail] We're not done yet Paul Wouters
- Re: [Endymail] We're not done yet Viktor Dukhovni
- Re: [Endymail] We're not done yet Paul Wouters
- Re: [Endymail] We're not done yet Viktor Dukhovni
- Re: [Endymail] We're not done yet Watson Ladd
- Re: [Endymail] We're not done yet Viktor Dukhovni
- Re: [Endymail] We're not done yet Stephen Farrell
- Re: [Endymail] We're not done yet carlo von lynX
- Re: [Endymail] We're not done yet Dave Crocker