Re: [dane] email canonicalization for SMIMEA owner names

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 12 December 2014 23:16 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEECC1A00CD for <dane@ietfa.amsl.com>; Fri, 12 Dec 2014 15:16:33 -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 qS47W6PbB531 for <dane@ietfa.amsl.com>; Fri, 12 Dec 2014 15:16:30 -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 2F8811A0025 for <dane@ietf.org>; Fri, 12 Dec 2014 15:16:30 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8294E282FBF; Fri, 12 Dec 2014 23:16:28 +0000 (UTC)
Date: Fri, 12 Dec 2014 23:16:28 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141212231628.GM25666@mournblade.imrryr.org>
References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <CABrd9SQ1umsP731hvghV92EL5y2P4i++ESyrvxUhJD==z=pKpw@mail.gmail.com> <F79847E4-C748-467F-ADA3-0DBCD5CFE697@nohats.ca> <20141212175242.GB25666@mournblade.imrryr.org> <m3bnn8xz31.fsf@carbon.jhcloos.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3bnn8xz31.fsf@carbon.jhcloos.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y3OG4sX6KHfgostxM2PE8SAV3m0
Subject: Re: [dane] email canonicalization for SMIMEA owner names
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: <http://www.ietf.org/mail-archive/web/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: Fri, 12 Dec 2014 23:16:34 -0000

On Fri, Dec 12, 2014 at 05:50:10PM -0500, James Cloos wrote:

> VD> of the protocol.
> 
> The only issue with using SRV is that the http GET path would have to be
> standardized, which could be an pain if the advertized MXs already serve
> https for something else.

I was thinking of multiplexing by port, rather than URI.  So that
the service in question really could be a light-weight HTTPS server
add-on to an MTA, rather than an HTTP application in a general
purpose HTTPS server.

The key advantage is that MTAs already have code for email address
parsing, table lookups, LDAP, ... and so operating a listener on
some custom port (from an SRV record) might not be a major burden.

The URI would then be "/".  The protocol would be some elaboration of:

    Client:
	GET /?email=<URL-encoded-address> HTTP/1.1
	Host: <hostname from srv record>
	Content-Length: 0

    Server:
	200 OK
	Content-Type: text/plain; charset=us-ascii
	Connection: close

	2 0 1 <trust-anchor digest>
	3 0 0 <encryption key>

This avoids encoding issues, UDP payload limits, and allows MTAs
to perform the necessary canonicalization to find the keys of
variant address forms.

The disadvantage of a service that's operated as part of the MTA,
is that people would have to deploy updated MTAs to support this.
It does however seem that this may be easier and more flexible than
populating per-user data into the DNS.

-- 
	Viktor.