Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 04 June 2014 13:44 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449201A0238 for <dane@ietfa.amsl.com>; Wed, 4 Jun 2014 06:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFVDNVGfn0I9 for <dane@ietfa.amsl.com>; Wed, 4 Jun 2014 06:44:50 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8A71A01F3 for <dane@ietf.org>; Wed, 4 Jun 2014 06:44:49 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DDF2C2AB1EB; Wed, 4 Jun 2014 13:44:41 +0000 (UTC)
Date: Wed, 04 Jun 2014 13:44:41 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140604134441.GN27883@mournblade.imrryr.org>
References: <OFB1999EAD.836E27A5-ON85257CE8.0067D557-85257CEB.000B5F5E@us.ibm.com> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <alpine.LFD.2.10.1406030056500.19868@bofh.nohats.ca> <20140603130839.GY27883@mournblade.imrryr.org> <m3ppip5s57.fsf@carbon.jhcloos.org> <20140604025535.GJ27883@mournblade.imrryr.org> <m3bnu93yzc.fsf@carbon.jhcloos.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m3bnu93yzc.fsf@carbon.jhcloos.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/A-oNT8s9uTDt9LA8VwvVyHN5FWA
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2014 13:44:52 -0000

On Wed, Jun 04, 2014 at 03:38:54AM -0400, James Cloos wrote:

> >>>>> "VD" == Viktor Dukhovni <viktor1dane@dukhovni.org> writes:
> 
> Perhaps I worded poorly.  Trying again.
> 
> It is OK for some document -- esp if it is a BCP -- to say that doing
> certain things can prove problemantic.
> 
> But even for a tls client which likes to try oob, and which only uses
> dane to verify oob, it is not unreasonable to try oob and if it fails
> try normal tls.  Without any need for user clicking, et alia.
> 
> That procedure should be rare; it SHOULD only occur when a destination
> is changing from supporting oob to not supporting it, and even then
> only if the dns got changed before the server's config.

If implementors don't think the issue though, they might well fail
and not retry.  I've seen enough "naive" and "cargo cult" code in
this space to be skeptical of likely implementation quality in the
absence of specific guidance.  Thus the OPS BCP should provide
specific guidance, alerting implementors to the issue, and advising
them of the simplest solution (skip oob when somewhat likely to
fail and the client implements use of PKIX certs).

> OTOH, multiple types of tlsa can exist for servers which support both
> oob and full cert clients.  Such servers may want to specify type 0,
> 1 or 2 for the full cert clients and type 3 for the oob clients.

You may recall my observations about mixing models ("PKIX" vs.
"DANE").

> I'm an example, in fact.  My web server has a paid cert for
> compatibility reasons, and I publish a 111 for it.

You allowed to needlessly torment users whose trusted CA list does
not include your issuing CA. :-)

> Since I'm wasting
> money on the cert, full-cert clients might as well pkix verify it.

This rationale is generally flawed, because were DNSSEC compromised,
the attacker would replace your 111 with a 311 of his choice.  Thus
the "111" is only useful in applications that refuse to mix models,
and only honour PKIX usages.

It is hard to say what the right policy is for browser-oriented
web sites, there is no application-specific definition of how or
whether browsers are to implement DANE authentication.  RFC 6698
is a generic template for application protocols, and does not
define browser behaviour.

> But since I'm fine with oob, once that becomes available for my sw
> I'd be happy to add a 311 to support it.  I'm certain other sites will
> have similar objectives.

If you're publishing 311, you obviate the 111 record, unless in fact
some specification appears that mandates PKIX usages in browsers, in
which case your "311" would only apply to some other class of clients.

> Avoiding oob in that case makes oob less useful than it might be.
> Especially if oob-only clients show up.

For single-model clients (those that only support PKIX usages or
those that only support DANE usages) the TLSA RRs for the unsupported
model are "unusable".  I should perhaps have mentioned (and will
in the BCP) that one first discards "unusable" TLSA RRs and only
then considers whether the *remaining* RRs are "oob compatible". 

> Sites like goog may have the same ideas even for their MXs.

Well, for SMTP, their only choices are DANE-TA or DANE-EE.  There
is no reason to mix the two.  The rationale for DANE-TA is operational,
you get to decouple server certificate updates from DNS updates, no
DNS changes for server key rotation:

	_25._tcp.mx1.example.com. IN CNAME dane-ta._tlsa.examle.com.
	_25._tcp.mx2.example.com. IN CNAME dane-ta._tlsa.examle.com.
	...
	_25._tcp.mxN.example.com. IN CNAME dane-ta._tlsa.examle.com.
	dane-ta._tlsa.example.com. IN TLSA 2 0 1 {blob}

if one publishes "311" along with it, all the benefit is lost, and
there is no reason whatever to also publish the "2 0 1".

> Because tlsa mis-configuration should be so rare, it also is OK for a
> client which finds itself in such a circumstance to abort completely.
> Oob-only clients will have to.

I've not introduced "misconfiguration" as a use-case.  All the
corner cases were properly configured.  Servers that need to support
"oob only" clients will need to publish "311" records, if they do
so in combination with other records, only "oob only" clients will
negotiate "oob".  Oob-only clients will find all incompatible TLSA
RRs unusable.  They can't do what I suggest and negotiate X.509
certs, so they are out of scope.

> VD> Authentication unnecessarily failing is indeed a big deal.
> 
> But this particular case should be most unusual.
>
> Most changeovers will follow the add-new-tlsa, change-server-config,
> remove-old-tlsa pattern.  Telling clients never to try oob when multiple
> tlsas are present means that transitions *to* oob would break if the
> middle step is change-server-only-to-do-oob or add-oob-too.

This glosses over key details.  For servers that publish only "3
1 X" records, transitions from one set of "3 1 X" records to another
just change the number of "3 1 X" records seen, and nobody suspends
use of "oob".  The only time use of "oob" is discouraged for clients
that support both "oob" and not, is when the transition mixes
(usable) TLSA usage/selector combinations.

> I have no objection to a document explaining to server admins what is
> likely to work and what is likely to fail.  And how each potential
> failure is likely to present.  And although it seems like miniscule
> should is enough when advising admins how best to deploy, I won't argue
> against SHOULD in such a document.

I will expand the advice (already needed for key rotation and digest
agility) for servers that covers how to transition between old and
new key material or TLSA RR types.  The same "product set" approach
combined with "change one feature at a time" indeed reduces potential
impact on clients that implement or honour only a subset of the
published record types.

> But telling clients they cannot TRY, or even SHOULD NOT TRY, just
> because a mis-configuration is possible, is too much.

What you characterize as a misconfiguration is not, unless we define
new server-side obligations.  Transition states are not misconfigurations.

If you are suggesting that the strategy I have in mind for "safe"
TLSA RRset updates is be a mandate, we can discuss that.  If indeed
the server is obligated to avoid non product-set mixed states, then
clients can always expect each C/U/M combination to contain at
least one RR that matches the servers "active" chain.

I've never seen such a requirement stated in any DANE WG document.
I am open to defining such a requirement, and publishing a methodology
for transitions between parameter sets that never violates such a
requirement.

> Even if all of the tlsas *are* 31x, there is no guarantee any will
> match.

Now we're talking misconfiguration, that's the server's fault.

-- 
	Viktor.