Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

Viktor Dukhovni <> Tue, 11 February 2014 23:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 96DA71A07AC for <>; Tue, 11 Feb 2014 15:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RHKVjpAUxZvn for <>; Tue, 11 Feb 2014 15:34:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EF8511A0799 for <>; Tue, 11 Feb 2014 15:34:05 -0800 (PST)
Received: by (Postfix, from userid 1034) id E393E2AB24A; Tue, 11 Feb 2014 23:34:03 +0000 (UTC)
Date: Tue, 11 Feb 2014 23:34:03 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt
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: Tue, 11 Feb 2014 23:34:08 -0000

On Tue, Feb 11, 2014 at 03:17:35PM -0700, Matt Miller wrote:

> Viktor (and DANE),
> Peter and I believe this revision addresses all of your feedback.
> Please let us if anything is missing or inconsistent.
> Also added an SRV example for the expected records, updated
> referenced, and author information.

The draft seems to use "indeterminate" in the sense of RFC 4033,
where-in there is no trust-anchor for the domain or any of its
ancestors.  Unfortunately, there is a conflicting definition in
RFC 4035, which I am told is more appropriate in this context.

All 4035-style "indeterminate" results (and "bogus" results) are
essentially lookup errors and must treated as such. See section
2.1 of the SMTP draft.  As for 4033-style indeterminacy it is indeed
to be treated as equivalent to "insecure".

For DANE-EE(3) CU records to have meaningful semantics for the
publisher.  For example for a publisher to use the same certificate
for many SRV hosts or without worrying about using a matching name,
the use of non-use of name checks must be specified precisely.

Therefore I would suggest that the "MAY be ignored" in the second
paragraph of section 5, should be changed to "MUST be ignored".
Otherwise, the published TLSA records have unknown semantics.

When the service domain is the head of a CNAME chain, with the SRV
record obtained after indirection via at least one CNAME RR, the
SMTP and ops drafts specify that name checks must include both the
service domain and its full CNAME expansion (in addition to any
SRV target host name).

The SMTP draft also specifies that servers MUST not refuse to
complete the TLS handshake when no certificate matching the SNI
name is present.  Rather they must then present the default
certificate, because clients may be willing to match other names
in addition to that sent in the SNI extension.

- In the first paragraph of 4.2, change "as describes" to "as described".

- In the third paragraph of 5. change "the the 'to' address" to
  eliminate the duplicate "the".