Re: [dane] WGLC: DANE-SRV & DANE-SMTP

[Sean Turner <[e-mail]>]

On Nov 12, 2014, at 23:09, Olafur Gudmundsson <[e-mail]> wrote:

> Dear wg members
> 
> This email message starts a three week WGLC ending on December 4’th at 23:59 UTC. 
> https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13
> 
> 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?

Nits:

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
 SHA2-256(1)

to: 

 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