Sean Turner <> Thu, 29 January 2015 15:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7EACB1A1AA9 for <>; Thu, 29 Jan 2015 07:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.433
X-Spam-Level: *
X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0uQ-dV4Fj6UK for <>; Thu, 29 Jan 2015 07:43:45 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 696931A1A87 for <>; Thu, 29 Jan 2015 07:43:45 -0800 (PST)
Received: by (Postfix, from userid 5007) id 95D6B257AEF66; Thu, 29 Jan 2015 09:43:44 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id 76774257AEE6A for <>; Thu, 29 Jan 2015 09:43:44 -0600 (CST)
Received: from [] (port=62180 helo= by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1YGrFv-0005xH-RC for; Thu, 29 Jan 2015 09:43:44 -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, 29 Jan 2015 10:43:42 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
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: 1YGrFv-0005xH-RC
X-Source-Sender: ( []:62180
X-Email-Count: 4
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, 29 Jan 2015 15:43:47 -0000

On Jan 22, 2015, at 17:08, Viktor Dukhovni <> wrote:

> On Thu, Jan 22, 2015 at 04:23:36PM -0500, Sean Turner wrote:
>> 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?
> Indeed the semantics of DANE-EE(3) are the same in both the ops
> and smtp-with-dane drafts.
> The ops draft ammends the semantics for all use-cases of the TLSA
> record by updating 6698.  The smtp-with-dane draft makes the same
> change only for opportunistic DANE TLS used in MTA to MTA SMTP.
> The history is that the decision to turn the ops draft into a 6698
> update happened rather late, and until that time, only the smtp
> draft had the requisite normative language.
> I don't know to best deal with this procedurally.  One might say
> that both drafts update 6698, or that only the ops draft does that,
> and the smtp draft applies just narrowly to the protocol at hand.
> I don't have any views on the logistics.

Multiple drafts can update one draft so if you want to save time you can just add
"Updates: 6698 (once approved)" to the header of both drafts and you’d be procedurally covered.  Well I guess technically, you need to also say “This draft updates RFC 6698” or something like that in the abstract of the nits checker will complain.

>> 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA is to unable forward
>    Muphry bites, but I know what you mean thanks.
>> 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.
> I'll add a forward reference, unless there is good reason to extend
> the terminology.

Nope that’ll work.

>> 2) s1.1: Couldn?t hurt to have informative references to DNS RR and RRSet.
> Sure.
>> 3) s1.2: r/Certificate Authority/Certification Authority
> Indeed, I thought I fixed all of those…

>> 4) s1.3.2: r/and requiring/and require
> This is a rather long sentence, but its high level
> structure is:
>    One might try to ... by using ... and requiring ...
> So I think that "requiring" agrees better with the
> preceding parts.  It might be clearer with an
> extra "by":
>    One might try to ... by using ... and by requiring ...
> Or a rewrite of the whole sentence.

I re-read it leave it as is.

>> 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.
> These looks largely the same to me, your version is fine too.

Yeah just moving some words.

>> 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.
> Makese sense.  The larger question is whether this is really the
> right place for a MUST NOT.  If the client gets this wrong it is
> insecure (never sees any "secure" domains and never uses DANE),
> but it is still interoperable.  What's the right way to tell clients
> that they don't get any security if their recursor is oblivious?

I think doing it here is fine.  There might be other places we’d also do it, but here I think is a fine place to start.

>> 7) s2.2.1: The text about MTA 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.
> I don't think there is any such text anywhere else.  The closest
> you'll find is "no misrepresentation of security" in RFC 7435
> (opportunistic security) of which this is an instance.

This is good to know and personally I’m fine with it.  I wonder if the mail folks won’t come unglued about this though because it’s imposing some kind of requirements on the MTA.  But, let’s see what they say before we try to second guess what might make it through.

>> 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.
> Sure, if there are no objections.

I guess we’ll see ;)

>> 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).
> Yes.
>> 10) s3.2.3: r/must be entire/must be the entire 
> Yes.
> When should the suggested changes be made?

Since we’re changing at least one 2119 keyword, I guess I’d go ahead and spin a new version before IETF LC - but that’s really up to the chairs.


> -- 
> 	Viktor.
> _______________________________________________
> dane mailing list