Re: [Endymail] We're not done yet

Viktor Dukhovni <> Mon, 17 November 2014 06:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D2691A0144 for <>; Sun, 16 Nov 2014 22:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id roSHp6aWP02z for <>; Sun, 16 Nov 2014 22:39:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A96B91A0137 for <>; Sun, 16 Nov 2014 22:39:50 -0800 (PST)
Received: by (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 <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [Endymail] We're not done yet
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

   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:

    and hope that these combinations cover all the likely variants.

2. Revocation, or where does one attach the horse to the motor car?

    - 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

    - 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.