Re: [dane] email canonicalization for SMIMEA owner names

Nico Williams <> Fri, 12 December 2014 04:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E83B1A1BA3 for <>; Thu, 11 Dec 2014 20:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 22fRRjyNJmQm for <>; Thu, 11 Dec 2014 20:14:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90CB11A6F9A for <>; Thu, 11 Dec 2014 20:14:24 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 3D48C20047B83 for <>; Thu, 11 Dec 2014 20:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to;; bh=Dy1CZoZkhLoWXb1ZR8ewiEbXP5Q =; b=kqFtT2Nj8aLyjcoq0L3/eN5A2Ts4ASfnotWNkEC/QjENUGFNHXpzmJ9XswM 8V15Wh+U1jMISaCq7bbR/COYI4LJpzW0fXhRolehq1Iv/r7Ta8CM9bsDBoB0MElj O5JtvuzIb/O9VSXZ6ruousMqgYKvqcvvY3rCgNWKK3+j73Os=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 0B4EB20047B80 for <>; Thu, 11 Dec 2014 20:14:23 -0800 (PST)
Date: Thu, 11 Dec 2014 22:14:23 -0600
From: Nico Williams <>
Message-ID: <20141212041419.GP3448@localhost>
References: <> <20141211221456.GI3448@localhost> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 04:14:25 -0000

On Fri, Dec 12, 2014 at 12:55:50AM +0000, Viktor Dukhovni wrote:
> On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote:
> > [stuff about indirecting via a keyserver elided]

SUBMIT/SMTP itself could act as the keyserver.

There are two use cases: validate a sender's signing certificate, and
get a recipient's encryption certificate.

Both mean contacting the peer's domain's keyserver, but we could
indirect through any SUBMIT server that the MUA can talk to, and we can
authenticate any replies via DNSSEC in a way that does not permit
walking the zone.


Client: connect to C's MSA
Client: VRFY_SENDER_CERT sender-local-part@sender.domain cert-hash
MSA: connect to sender.domain's MTA
MSA: VRFY_SENDER_CERT sender-local-part@sender.domain cert-hash

The MTA responds, the MSA forwards the response.  The client also does a
DNS lookup for base32(H(sender certificate || sender
address))._smimesendercert.sender.domain. and [hopefully] finds
base32(H(sender address)).

No need for the client to talk to sender.domain's MTA directly, so no
concerns about port 25 blocking.

And if the MSA lies, the client will find out.

The client has to speak SUBMIT/SMTP anyways, and it has to support doing
so with TLS (which the client's MSA surely will speak, and the network
damned well ought to permit).

> The downside of something other than HTTPS or DNS, is that while
> less likely to be blocked for anti-spam reasons, this is likely to
> be inaccessible to MUAs inside various firewalled environments.

See above as to firewalls.  But it's true that a pure DNSSEC scheme
means that the client can encrypt e-mail to / validate e-mail signatures
without having to worry about downgrade attacks on SMTP.  We'd still
want the client to use TLS for SUBMIT/SMTP though.

A middle of the road might be that domains could publish RRSets for
local-parts they don't mind people being able to walk, but not for those
they do, with the trade-off being that the latter lose security (or
access) when networks attempt MITM downgrade attacks on StartTLS.

> Perhaps a sufficiently light-weight http encapsulation is right
> after all, and MTA authors might be able to implement just enough
> HTTPS to still support this as an MTA feature.


> [...]
> This however takes far away from any similarity to the SMIMEA draft
> as it is today.  Is it really time to throw it all away and start
> again?

Maybe so.