Re: [dane] Digest Algorithm Agility discussion
Wes Hardaker <wjhns1@hardakers.net> Thu, 20 March 2014 22:12 UTC
Return-Path: <wjhns1@hardakers.net>
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 D4BAB1A091D for <dane@ietfa.amsl.com>; Thu, 20 Mar 2014 15:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 Rlcrf06TH0MH for <dane@ietfa.amsl.com>; Thu, 20 Mar 2014 15:12:40 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCC01A08E0 for <dane@ietf.org>; Thu, 20 Mar 2014 15:12:39 -0700 (PDT)
Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id D201D27168; Thu, 20 Mar 2014 15:12:25 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Viktor Dukhovni <viktor1dane@dukhovni.org>
References: <20140315051704.GY21390@mournblade.imrryr.org>
Date: Thu, 20 Mar 2014 15:12:23 -0700
In-Reply-To: <20140315051704.GY21390@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 15 Mar 2014 05:17:04 +0000")
Message-ID: <0l4n2sa5a0.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NjsiKjQ-btjyDyz-3uKdKo5urC4
Cc: dane@ietf.org
Subject: Re: [dane] Digest Algorithm Agility discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Thu, 20 Mar 2014 22:12:42 -0000
Viktor Dukhovni <viktor1dane@dukhovni.org> writes: > The SMTP draft specifies a digest algorithm agility protocol for DANE. So, trying to review this thread for where things stood and a number of things jumped out at me. Specifically, there is a lot of violent agreement on some things. So let me get the most important out of the way that I'm firmly convinced everyone agrees on: local policy always trumps everything. EG this is perfectly acceptable: if moon == full: acceptable_alg_list = [GOST] else if elvis == reborn or the_beetles == on_tour: acceptable_alg_list = [MD5, SHA51] prefer = any_match else acceptable_alg_list = [SHA512, SHA256] prefer = first_existing_alg_published_from_list And that (wacky) policy would always trump any other decision tree in the code base. Where things have been falling apart are o o What is the default for "prefer", any_match [most people's opinion] or first_existing_alg_published_from_list [Viktor's opinion]? To really consider this, we have to take a few things into account: o The server is unable to publish, for their clients, their preference order. There is no way to make the statement "please authenticate my certificate using SHA256. Unless you don't understand it, in which case just use SHA1". The *only* thing it can do is publish things it trusts and hope the client uses the best one available, for which it has no say. o The client gets to pick what it's willing to accept and what it's not. o But, there are two sides to DANE. 1. DANE is augmented security to the base infrastructure. Rather than allowing 1300+ X.509 CAs, it restricts the connection to a single, linear X.509 path (tied to a single, linear DNSSEC path). This is certainly the case for the HTTP case. Even a MD5 hash to double check the CA path is likely an improvement to the non-DANE case. It's an *added* check to the existing infrastructure. So clients are more likely to be willing to accept nearly anything "not broken". 2. DANE is *the* security mechanism, and without it you simply can't do some aspect of security. In the SMTP case, it is impossible to do authentication without a DNSSEC/DANE solution. 6698 was not originally written to cover this case (and, as discussed recently, this all hinges on "discovery" and that was deliberately left out of past solutions). In this case, it's much more likely someone may want a policy of "if they indicated they can do my most preferred algorithm, then don't transmit the message if that algorithm is failing. I don't care if there is another match to a less preferred one. o Now for case #2, it'd be easy to simply thing "look, just don't specify MD5 if you don't trust it". But that's not so simple when it comes to connecting to random machines in the world. It'd be great to have a policy of "Only accept SHA256 from example.com, but accept either SHA256 or SHA512 from example.org if either works". That that's not a manageable policy to maintain for the internet at large. So where does that leave us? With a choice. What do we want as a policy knob. The choice: Do you, Mr. System Administrator defining the local policy for the *client*, want: A) Accept any published hashing algorithm out of my "unordered set" to validate the remotely presented certificate. [Ordering it doesn't buy you anything since you'll simply accept a match and it doesn't matter which you try first, since any success in any algorithm will equally indicate "ok"; in fact in an implementation aiming for speed, it might be best to choose the order based on how fast you can execute the algorithm]. If the server fails to publish a perfect record set, as long as one matches I'm ok with that. B) Believe that the server will always publish perfect records, and if my "ordered set" of algorithms is [SHA512, SHA256] and they publish SHA512, then I never want to accept SHA256 because I fear an attack more than I fear a server administrator blowing their configuration. So to recap, first: either of those is fine in local policy knob setting scheme. Implementations can let administrators of clients configure sane or insane policies they want. But the real question, is what is the *default* that we should suggest an implementation do? RFC6698 indicates choice A ("accept anything that matches in my unordered set"). But, what about other specific protocols? I) what should we do generically? RFC6698 already laid this out as A in absence of local policy. II) what should we do in SMTP? This is where Viktor, considering case #2 above, is wanting to do B ("accept just the 'best' in an ordered set of algorithms) instead of A. The arguments, though, from both sides are probably talking about different cases (generic vs SMTP) and I think that is ending up with some of the confusion. Here's the multiple choice quiz to cap all this off: 1. For generic DANE, is the right *default* choice: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 2. For SMTP, is the right (SMTP-application-specific) *default* choice: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 3. For XMPP: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 4. For HTTP: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 5. For IMAP: .... -- Wes Hardaker Parsons
- [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Martin Rex
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion (c… Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Jim Schaad
- Re: [dane] Digest Algorithm Agility discussion (c… Paul Hoffman
- Re: [dane] Digest Algorithm Agility discussion (c… Andrew Sullivan
- Re: [dane] Digest Algorithm Agility discussion (c… Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion (c… Scott Rose
- Re: [dane] Digest Algorithm Agility discussion (c… Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion (c… Scott Rose
- Re: [dane] Digest Algorithm Agility discussion Wes Hardaker
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Mark Andrews
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Paul Wouters
- Re: [dane] Digest Algorithm Agility discussion Viktor Dukhovni
- Re: [dane] Digest Algorithm Agility discussion Peter Palfrader
- Re: [dane] Digest Algorithm Agility discussion Wes Hardaker
- Re: [dane] Digest Algorithm Agility discussion Wes Hardaker