Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt

Viktor Dukhovni <> Tue, 11 November 2014 00:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0FF901A6EE9 for <>; Mon, 10 Nov 2014 16:13:27 -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 P-tulfdz_3p2 for <>; Mon, 10 Nov 2014 16:13:25 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EF3A1AC44C for <>; Mon, 10 Nov 2014 16:13:25 -0800 (PST)
Received: by (Postfix, from userid 1034) id 3C1B42AB24B; Tue, 11 Nov 2014 00:13:24 +0000 (UTC)
Date: Tue, 11 Nov 2014 00:13:24 +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.23 (2014-03-12)
Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 00:13:27 -0000

On Mon, Nov 10, 2014 at 11:49:15PM +0000, Dan York wrote:

> All of these would seem to be related to operational processes where some
> part of the security layers get updated without other corresponding layers
> being also updated.

That's definitely the main problem.  Though
to be fair with HTTPS sites, nobody cares if they don't verify,
browsers don't do DANE and seem unlikely to do so in the near
future.  [ Yes, folks like us might install a plugin, which may or
may not work correctly. :-( ]

I think more/better tools to validate the configuration, and
awareness of those tools will help, as will the relevance of getting
the records right.  If TLSA records are just a fashion statement
with no operational significance, the bits will rot.

For SMTP at least, one of these days people getting their records
wrong might actually feel some pain in the form of delayed mail,
and then the problem may start to self-correct as people acquire
the appropriate operational habits.  That would be accelerated by
a large sender or two enabling opportunistic DANE TLS for SMTP.

No large providers appear in my curated list of 330 DANE-enabled
SMTP domains.  Though, IIRC, Unity Media in Germany has ~500,000
users, which is nice, but not quite the requisite scale.

Speaking of SMTP, the same deploy360 site lists some SMTP test
domains.  I'd like to suggest removal of, or (with
his consent) adding that domain to a new category, his records are
PKIX-EE(1), and are not aligned with the DANE SMTP draft.  (Per
the draft, these would be treated "unusable" in SMTP, resulting in
a sender policy of mandatory unauthenticated TLS).