Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

Warren Kumari <> Mon, 17 February 2014 19:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 781331A01F9 for <>; Mon, 17 Feb 2014 11:54:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I95iafWyQJXU for <>; Mon, 17 Feb 2014 11:54:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D1E711A0257 for <>; Mon, 17 Feb 2014 11:54:05 -0800 (PST)
Received: by with SMTP id u56so1061815wes.31 for <>; Mon, 17 Feb 2014 11:54:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TMY9XiZ+68RValVW2UUI7zEjDjv1ehHZqMTpy9NlLGc=; b=fime9T8VFm+0K7k7t283uFmv9ae5YzvbHztF/ynyE45hkr/p/0Y3aU9UhgllpCd76W WWeCC0iWMXgNbQM9V73rLKvSJASEMYRoCj96oOjHuNaQrRT7vzpq49RBhtXFqYqV9ONZ 5gsAbyfs4OBSFsJsw1Jx3sUYJdOybZpEt5A6/maDG8RzY+H9GHQ8hvC6YmHQO9a8f5eZ Q/FWyvf9CdZ2ahOK575lijjAMtL6Ei52nylJOH8MevrSjmRHS0WLmBkMYvxkLiAZtMpQ CZXLWWa2/NqivVNYU8b9M6xRceHmOKN9TiHqGVDSdSKEJOVaoHbVse01EZFUcyJPkOZy khdw==
X-Gm-Message-State: ALoCoQm9D68jX4Jqe1CmFGvfKTWz21jR3FefeAlVF7c4bC2fnOvCxmxYjx91s8xO1Xn2d2lalzpQ
MIME-Version: 1.0
X-Received: by with SMTP id hh9mr12290wjb.89.1392666842524; Mon, 17 Feb 2014 11:54:02 -0800 (PST)
Received: by with HTTP; Mon, 17 Feb 2014 11:54:02 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <>
Date: Mon, 17 Feb 2014 14:54:02 -0500
Message-ID: <>
From: Warren Kumari <>
To: Paul Hoffman <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
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: Mon, 17 Feb 2014 19:54:36 -0000

On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman <> wrote:
> On Feb 14, 2014, at 2:50 PM, James Cloos <> wrote:
>> The only real question is whether dane-srv and dane-smtp-with-dane
>> should be published as two rfcs or combined into one?
>> (I'm leaning towards two, numerically adjacent.)
> With all due respect, there are other real questions, much more significant than that one.
> One of the biggest questions that needs to be asked is not whether DANE can be used for opportunistic protocols, because of course it can, but whether DANE can be used to determine whether a server at a domain name "should" be speaking TLS at the time that a client tries to connect. Viktor makes a strong case that it does for SMTP. During the early discussions of TLSA, many people thought it should not.

And some thought that it should -- IIRC, this, like many of the early
DANE discussions was fairly heated, and the consensus was far from
We ended up with a number of compromises simply so that we could make

Again, IIRC there was a suggestion that the TLSA record should be able
to signal if clients may continue without TLS / perform something
analogous to HASTLS / HSTS. This could have been a single bit, or yet
another byte.
We decided not to do that, but I wonder if in light of recent
revelations we should revisit this decision. I'm not quite sure how
we'd cram this into the current record, if it should be defined in
each of the "DANE with foo" docs or if it would require yet another RR

> Viktor's view gives us good MITM protection if the DNS channel is not broken and the client knows the DNSSEC status of its query. It also causes messages to be lost if there is an operational problem or even an unexpected mis-match on the crypto desires of the client and server. It also assumes that the person running the DNS server for a name is in active contact with the person operating the SMTP server.
> Personally, I don't care about MITM protection if it comes at the cost of getting more organizations to turn on opportunistic crypto. I think DANE still has an important role in that it gives the SMTP server operator a logging capability to see if there is an MITM. Others prefer more protection against MITMs even in the face of preventable communication failures.

Or we could give the person publishing the RR the ability to specify.

> And, to be blunt, if we think that Viktor is right about DANE for SMTP, shouldn't DANE for HTTP have the same MITM protection and operational downsides?

Personally I think that it should, but I might be in the weeds here.

> --Paul Hoffman
> _______________________________________________
> dane mailing list