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.
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Hoffman
- [dane] Extending TLSA RFC to operate with TLS's n… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Wes Hardaker
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Jim Schaad
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Tom Gindin
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Stephen Farrell
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Olafur Gudmundsson
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Stephen Farrell
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Simon Arlott
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Servers which offer RPK but have no TL… John Gilmore
- Re: [dane] Servers which offer RPK but have no TL… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Servers which offer RPK but have no TL… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Servers which offer RPK but have no TL… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- [dane] Extending TLSA RFC to operate with TLS's n… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni