Re: [dane] Review of DANE SMTP draft

Lawrence Conroy <> Fri, 14 March 2014 19:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B2A4C1A00A9 for <>; Fri, 14 Mar 2014 12:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kM7s4D5_hai5 for <>; Fri, 14 Mar 2014 12:34:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CFAB21A0092 for <>; Fri, 14 Mar 2014 12:34:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12D3A143C8B9 for <>; Fri, 14 Mar 2014 19:34:44 +0000 (GMT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rys0LQC-3mrC for <>; Fri, 14 Mar 2014 19:34:43 +0000 (GMT)
Received: from [] (localhost []) by (Postfix) with ESMTPSA id 16DE6143C8AE for <>; Fri, 14 Mar 2014 19:34:43 +0000 (GMT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Lawrence Conroy <>
In-Reply-To: <>
Date: Fri, 14 Mar 2014 19:34:42 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.1085)
Subject: Re: [dane] Review of DANE SMTP draft
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: Fri, 14 Mar 2014 19:34:54 -0000

Hi Viktor, Alexey, folks,

Please, please, please do NOT give invalid/incorrect examples (even as examples of what NOT to do).

Viktor: The text you have seems pretty obvious to me on reading.
To nail it in with a hammer, maybe c/when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if the MTA chooses/Even though this form is invalid, some MX RRsets may be encountered that list a network address in lieu of an MX hostname. If the MTA nevertheless chooses/
(but that really is smashing the point home).

Now back to lurking.

all the best,

On 14 Mar 2014, at 17:41, Viktor Dukhovni wrote:
> On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote:
>>> [ Second-last paragraph of 2.2 ]
>>> Is it not obvious that this means the misguided:
>>> IN MX 0
>> No, it is not obvious, otherwise I wouldn't have asked.
> The original sentence reads:
>    Similarly, when an MX RRset incorrectly lists a network address in
>    lieu of an MX hostname, if the MTA chooses to connect to the network
>    address, DANE TLSA does not apply for such a connection.
> Anyone else feel this deserves an example?  There are some poor
> sods who attempt to stuff IPv4 addresses into MX hostname RRDATA,
> and some MTAs may do them a favour and handle this broken syntax.
> In that case DANE is clearly out of scope.
>>> In 6125 (where the exceptions dominate the rules) there are no
>>> provisions for matching one of a set of candidate names.
>> I am not sure I understand. If there are multiple subjectAltName
>> values of the same type, any match works. Unless you mean something
>> else.
> No, the SMTP and SRV drafts specify that the client has multiple
> names it is willing to accept, any one of which may match one of
> the many SAN names in the peer certificate.  There can be up to
> three names.  The original name before redirection by MX or SRV,
> the securely CNAME expanded version of that if different, and
> finally the TLSA base domain of the server.
>>> I don't know whether the Postfix (on by default) Postini work-around
>>> deserves IETF blessing.  Perhaps it would be better for Postini to
>>> fix their certificates,
>> I think so, yes.
> That is Postini fix their mess?  Or SMTP support multi-label
> wildcards?
>>> RFC 6066 is referenced on page 6 (second last paragraph) and appears
>>> in the References section.  Should the reference be repeated on
>>> page 22?
>> In general, I prefer when references are repeated.
> We can do that.  There is clearly sufficient distance between page
> 6, and page 22, for the reference not to appear repetitive.
>>>> In 2.3.3: it is not clear whether the client needs to check that for every
>>>> record covered by the WORSE hash there is a corresponding record covered
>>>> by the BETTER hash.
>>> This is not possible.  The records don't carry separate "instance"
>>> identifiers that allow one to identify all the TLSA records of a
>>> single certificate or public key.  The various digest algorithms
>>> are not invertible!  All that the client can check is that the
>>> number of records for the best algorithm is the same as that for
>>> all other algorithms within each combination of usage and selector.
>> I think your current text can be misinterpreted that such validation
>> is allowed. Use of normative language didn't help. I think I
>> interpreted some of the requirements as applying to SMTP clients,
>> where they applied to ISPs.
> What do you mean by "such validation is allowed"?  Would you mind
> starting a new thread with questions specifically about the digest
> agility part of the SMTP draft?  This mechanism is not intended to
> be SMTP-specific, and should some day make it into DANEbis via the
> SRV draft as a first hop perhaps (unless it should be its own
> stand-alone draft on just digest agility for DANE).
>>>> I've heard Not checking expiration dates in certificate - I don't think
>>>> this was mentioned in the document.
>>> This is in the "ops" draft, but I'll add it to the description in
>>> the SMTP draft, after we figure out exactly what should be ignored
>>> in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor
>>> certs).  (Separate thread on this soon).
>> Ok. If you are departing from RFC 5280, they you should state all
>> new requirements.
> Yes.
> -- 
> 	Viktor.
> _______________________________________________
> dane mailing list