Re: [dane] email canonicalization for SMIMEA owner names

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 12 December 2014 00:31 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 3E1431A90C5 for <dane@ietfa.amsl.com>; Thu, 11 Dec 2014 16:31:34 -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 w5KNgW8qwbpu for <dane@ietfa.amsl.com>; Thu, 11 Dec 2014 16:31:32 -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 93EB51A90C0 for <dane@ietf.org>; Thu, 11 Dec 2014 16:31:32 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23782282F8B; Fri, 12 Dec 2014 00:31:31 +0000 (UTC)
Date: Fri, 12 Dec 2014 00:31:31 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141212003130.GQ25666@mournblade.imrryr.org>
References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20141212000953.B0FE5254EAE8@rock.dv.isc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VFy8mG0tmow2OiUFcBRMatnT3G4
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 00:31:34 -0000

On Fri, Dec 12, 2014 at 11:09:53AM +1100, Mark Andrews wrote:

> We could just do this correctly and use SRV records to point to
> keyserver servers running over TLS.  The keyserver can do whatever
> local canonicalisations that are required.  The SMTP server could
> even be performing this role on a different port.  That way you
> only have to enter the canonicalisation rules once.
> 
> This also gets rid of the complaints about being able to walk the
> zone.

Since this is the DANE working group, those would be DANE TLSA
authenticated servers, designated via a suitable SRV record.

The presence of the SRV record itself would signal adoption of the
protocol by the domain.

However, this makes the protocol much more complex.  Mail clients
that just do local submission and did not need a TLS stack, would
now need to implement HTTPS, and we'd end-up defining a rather
complex protocol layered over that.

DNS does scale better.

If we're really going to do this as a direct query to the remote
domain (and not a DNSSEC lookup), perhaps the right application
protocol is some sort of minimal SMTP over SSL on a port indicated
by the SRV record:

    <tcp connect>
    C/S: <TLS handshake>
    C: SMIMEA "Frank.Jr."@example.com
    S: 250-3 1 1 <blob1>
    S: 250 3 1 2 <blob2>
    <TCP disconnect>

HTTP seems like much too much baggage, and the above could actually
be an additional service operated as part of the MTA, (the email
administrator would not need to be either a DNS administrator or
a webmaster).  The SMTP server would know how/whether to case-fold
the address.

-- 
	Viktor.