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.