Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 31 May 2014 19:37 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 5DF901A0087 for <dane@ietfa.amsl.com>; Sat, 31 May 2014 12:37:17 -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 JTYbwgGpP2l3 for <dane@ietfa.amsl.com>; Sat, 31 May 2014 12:37:14 -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 934441A007F for <dane@ietf.org>; Sat, 31 May 2014 12:37:14 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E69C42AB143; Sat, 31 May 2014 19:37:08 +0000 (UTC)
Date: Sat, 31 May 2014 19:37:08 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140531193708.GI27883@mournblade.imrryr.org>
References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <alpine.LFD.2.10.1405291257210.14277@bofh.nohats.ca> <20140529180356.GL27883@mournblade.imrryr.org> <m3a99zgkdk.fsf@carbon.jhcloos.org> <20140530192840.GC27883@mournblade.imrryr.org> <m3mwdyg7do.fsf@carbon.jhcloos.org> <20140531011048.GE27883@mournblade.imrryr.org> <m3r439bwrq.fsf@carbon.jhcloos.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m3r439bwrq.fsf@carbon.jhcloos.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ALOmNxxTu_T0nNJgNyaDaNWR1n4
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: Sat, 31 May 2014 19:37:17 -0000
On Sat, May 31, 2014 at 02:58:08PM -0400, James Cloos wrote: > VD> If the TLSA records don't include any [3-0-0 or 3-1-x], or are > VD> mixed, the client must not negotiate "oob public key". > > That is a valid point, but if they are mixed, the clients can try, and > if the offered key doesn't match the suitable tlsas, it can drop the > connection and try again without specifying the extension. To what end? The server recently had, has now or soon will have TLSA records that require full certificates. The server should be able to offer a matching certificate, containing a suitable key. I am not a fan of various fallback schemes and associated downgrade attacks. > When properly configured, if the server's only current cert(s) is full, > then the server should not agree to the tls extension. The need to drop > and restart should be rare. The need for the client to not offer "oob public key" will also be rare, generally servers won't have mixtures of different C/U values across key rollover. Some sites will have only "2 0 1" records: ;; Key rollover state: ;; Current and either future or recent past associated data example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1} example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob2} while other sites will have only "3 1 1" records: ;; Key rollover state: ;; Current and either future or recent past associated data example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob1} example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob2} and the mixed cases will only be seen briefly in transition between the two models. That said, transitions should not be disruptive. A client that sees: ;; Trust model rollover state: ;; Current and either future or recent past associated data example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1} example.com. IN TLSA DANE-EE(3) Cert(1) SHA2-256(1) {blob2} has no idea whether the "3 1 1" record is sufficient for authentication, and should simply not offer to negotiate bare public keys (unless it it is statically configured to authenticate these by other means, and the DANE records are largely out of scope). -- 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