Sean Turner <> Thu, 22 January 2015 21:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F0481B2A4E for <>; Thu, 22 Jan 2015 13:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.567
X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2P8uo34gykQw for <>; Thu, 22 Jan 2015 13:23:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEB2A1B2A4B for <>; Thu, 22 Jan 2015 13:23:38 -0800 (PST)
Received: by (Postfix, from userid 500) id 663128B6BF165; Thu, 22 Jan 2015 15:23:38 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id 520D58B6BF142 for <>; Thu, 22 Jan 2015 15:23:38 -0600 (CST)
Received: from [] (port=51273 helo= by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1YEPE1-0004wb-Op for; Thu, 22 Jan 2015 15:23:37 -0600
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner <>
In-Reply-To: <>
Date: Thu, 22 Jan 2015 16:23:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "<>" <>
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Exim-ID: 1YEPE1-0004wb-Op
X-Source-Sender: ( []:51273
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: <>
Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP
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: Thu, 22 Jan 2015 21:23:42 -0000

On Nov 12, 2014, at 23:09, Olafur Gudmundsson <> wrote:

> Dear wg members
> This email message starts a three week WGLC ending on December 4’th at 23:59 UTC. 
> These two document are specifying related uses of DANE. 
> Please review the documents carefully, in particular we want to make sure the documents have no 
> contradictions. 

Apologies again for being late.  Here are my comments on the DANE SMTP draft.  Though pretty dense, I think this is a well written document that does a good job explaining why you might want to deploy this as well as how to deploy it.  Got one major (procedural thing) but the rest are editorial:

This is procedural but I guess it’s major:

Am I right that this draft is using the new definition for DANE-EE that is documented in draft-ietf-dane-ops?  Don’t we have to wait for it to update RFC 6698 or does this specification have to indicate that it updates RFC 6698?


0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA is to unable forward

1) s1.1, delayed delivery: Might be good to have a forward reference to “mandatory DANE TLS” in the later section or add it as a definition in s1.1.

2) s1.1: Couldn’t hurt to have informative references to DNS RR and RRSet.

3) s1.2: r/Certificate Authority/Certification Authority

4) s1.3.2: r/and requiring/and require

5) s1.3.3: What I think you’re trying to say here:

 Sending systems are in some cases explicitly configured to use TLS
 for mail sent to selected peer domains.   This requires sending MTAs
 to be configured with appropriate subject names or certificate
 content digests to expect in the presented server certificates.

is this:

 Sending systems are in some cases explicitly configured to use TLS
 for mail sent to selected peer domains, but this requires configuring
 sending MTAs with appropriate subject names or certificate
 content digests from their peer domains.

6) s2.1.3: I think if we’re going to have a “MUST NOT” for something it’s probably worth a pointer to the definition in RFC 4033 for "Security-Oblivious stub-resolvers” or add it to s1.1 and point to RFC 4033.

7) s2.2.1: The text about MAT delivery logs made me wonder where the rest of the normative behavior is for MTA delivery logs and whether this text is updating that text.

8) s3.1: Should this be "RECOMMEND":

  In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
  SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
  depending on site needs.

9) s3.1: Maybe reword:

 The mandatory to support digest algorithm in [RFC6698] is


 As specified in [RFC6698], the mandatory to implement digest
 algorithm is SHA2-256(1).

10) s3.2.3: r/must be entire/must be the entire