Re: [dane] email canonicalization for SMIMEA owner names

Viktor Dukhovni <> Fri, 12 December 2014 17:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 674571ACE61 for <>; Fri, 12 Dec 2014 09:53:13 -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 SDuael3ekxO3 for <>; Fri, 12 Dec 2014 09:53:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AD3B1ACEAB for <>; Fri, 12 Dec 2014 09:52:43 -0800 (PST)
Received: by (Postfix, from userid 1034) id 7C2BC282FBF; Fri, 12 Dec 2014 17:52:42 +0000 (UTC)
Date: Fri, 12 Dec 2014 17:52:42 +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: [dane] email canonicalization for SMIMEA owner names
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Dec 2014 17:53:13 -0000

On Fri, Dec 12, 2014 at 10:38:13AM -0500, Paul Wouters wrote:

[ NOTE:  I am not advocating abandoning SMIMEA, just thinking out
  loud about what an alternative might look like, since some folks
  seem to want to discuss alternatives. ]

> Whoever starts using variant email addresses should publish
> records for it? As John said, clients shouldn't start guessing
> addressing schemes used by others

With address extensions, There may not be such a list to publish,
all extensions are valid.  In


The <address-extension> part is any string that is not too long to
fit into SMTP commands and email headers.

If queries are sent to an HTTPS service that is deployed with the
(ultimate) inbound MTA for "", then X.509 key lookup is
rather similar to what the MTA already does to validate the inbound
recipient so as not to be a backscatter source.

The HTTPS service would be operated as part of the organization's
boundary MTA (thus with MessageLabs, Postini, ... in proxy rather
than hosting mode, not as part of those services, but as part of
the real border system accepting mail from those).

The presence of the associated SRV records would signal adoption
of the protocol.  Domains that employ filtering services such as
MessageLabs, Postini, ... might publish only signing keys if they
wish for all email to be scanned and don't want end-to-end encryption,
or might allow end-to-end encryption via user to user requests (you
can only get my encryption key if I reply, the protocol only yields
signature verification data).

The main thing this would have to recommend itself is there is no
encoding of the localpart into DNS labels, the HTTPS service can
support queries with the full EAI address as-is, and can easily
grok the address extensions, etc., because the MTA already knows
how to do that.  DANE would be used to authenticate that service,
and the data coming back from the service would still be RFC 6698
style (usage,selector,mtype,data) associations.  This would just
be a variant oracle that avoids encoding email addresses in DNS.

The oracle can query LDAP, ... can make up fake replies for
non-existent addresses to thwart directory harvesting attacks
if desired, ...

HTTPS, allows the service to be reached from inside corporate
environments that block most other outbound services (possibly
including external DNS).  In some environments even HTTPS is subject
to corporate MiTM (that the users are aware of with the HTTP proxy
signing certs trusted by browsers, ...).  In such environments
users don't get end-to-end email encryption, just like they don't
get end-to-end HTTPS.  Their border email gateway might be able to
play gateway-to-gateway SMIME with the destination.