Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 06 June 2014 02:31 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 317D51A03BF for <dane@ietfa.amsl.com>; Thu, 5 Jun 2014 19:31:24 -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 ez3BupBxBVlF for <dane@ietfa.amsl.com>; Thu, 5 Jun 2014 19:31:22 -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 88DFE1A03BD for <dane@ietf.org>; Thu, 5 Jun 2014 19:31:22 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AB1E12AAB4F; Fri, 6 Jun 2014 02:31:14 +0000 (UTC)
Date: Fri, 06 Jun 2014 02:31:14 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140606023114.GT27883@mournblade.imrryr.org>
References: <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> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <201406060140.s561esBT021883@new.toad.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201406060140.s561esBT021883@new.toad.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uVmO7AjIkK_LDGhjWdWuD0MVduo
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: Fri, 06 Jun 2014 02:31:24 -0000
On Thu, Jun 05, 2014 at 06:40:54PM -0700, John Gilmore wrote: > > Finally, the WG could decide that servers which publish U/S/M > > combinations in their TLSA RRset that contain only future or only > > past keys are "misconfigured", and that servers SHOULD NOT do that. > > I don't understand how any crypto protocol can succeed when it > authenticates only past or future keys, not the keys in present use. Not *only*, rather concurrently both present and either past or future keys (possibly all three, but that's generally unnecessary). > Can you explain why you think such a server is NOT misconfigured? During administrative changes in the TLSA RRset, given the asynchronous nature of DNS data propagation, one needs to insert future data before removing present data. Once the new keys are in place, one can remove past data. At various stages clients see one of: * (old) present * (old) present + (new) future * (old) past + (new) present * (new) present No *proper* subset of the TLSA RRs is currently mandated to contain a record matching the server chain. Only the *complete* RRset of a correctly configured server must contain *at least one* matching record. If the usage/selector/mtype combinations for "old" and "new" chains are not identical (one to one correspondence) then a client that employs a proper subset of the TLSA RRs (say because RPK is only capable of matching "3 1 X"), then it might be that this subset contains only past or only future keys and authentication fails. > Or > perhaps you will agree that this is misconfiguration, but you think > that for some reason that you can state, many people will foolishly > misconfigure their servers this way, such that the protocol should > gracefully handle that "common misconfiguration" case? No it is not misconfiguration as currently defined. We could publish operational requirements that make it a misconfiguration or at least a violation of best practice. Is that enough for clients to throw caution to the wind and assume consistent BCP TLSA RR practices on the server side? Perhaps it is safer for the client to forgo an optimization and just negotiate X.509 in some edge cases that will be rare, but not unlikely enough to not cause people real support issues. The best example for PRK is a transition from a current "2 0 1" TLSA RRs to future "3 1 1" RR. The administrator needs to know to do: Initial: IN TLSA 2 0 1 {old TA} Intermediate: IN TLSA 3 1 1 {switch to old leaf} IN TLSA 3 1 1 {new leaf} Final: IN TLSA 3 1 1 {new leaf} rather than the more naively obvious: Initial: IN TLSA 2 0 1 {old TA} Intermediate: IN TLSA 2 0 1 {old TA} IN TLSA 3 1 1 {new leaf} Final: IN TLSA 3 1 1 {new leaf} because here, until the new leaf is deployed after the original TTL expires, PRK clients might conclude that it is safe to use PRK, but it is not because the server's current (old) key can't be matched via an EE SPKI association. Asking the server operator to disable PRK (which be negotiated automatically in some toolkit whenever the client asks just because the server also has the feature) when the published TLSA records might not be PRK friendly is I think a greater burden than asking for care in how DNS records are updated. This is an operational issue for both client and server, someone has to do the heavy lifting. I think the client should not be entirely off the hook, because PRK for clients that support both X.509 and PRK is an optional optimization. The impact will be low, because servers that support "3 1 X" will most often only support "3 1 X", and the "mixed" RRsets will be very rare. -- 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