Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05

Stephen Kent <kent@bbn.com> Fri, 08 January 2010 14:08 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F343A6862 for <secdir@core3.amsl.com>; Fri, 8 Jan 2010 06:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNCcVJYV52xG for <secdir@core3.amsl.com>; Fri, 8 Jan 2010 06:07:59 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3B6313A67B5 for <secdir@ietf.org>; Fri, 8 Jan 2010 06:07:59 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NTFV8-0003vG-9v; Fri, 08 Jan 2010 09:07:42 -0500
Mime-Version: 1.0
Message-Id: <p06240818c76c1a38cbf8@[128.89.89.161]>
In-Reply-To: <20100107222809.GA25747@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com>
Date: Fri, 8 Jan 2010 09:07:24 -0500
To: Andrew Sullivan <ajs@shinkuro.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-949162835==_ma============"
Cc: Ralph Droms <rdroms@cisco.com>, dol@cryptocom.ru, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 14:08:00 -0000

Andrew,

I think the arguments I made are not so tightly related to the 
question of the ability of the protocols in question to negotiate 
algorithms, but I do appreciate the questions you posed.

You are correct that IPsec peers and TLS clients & servers perform a 
negotiation prior to establishing a session or secruity association. 
However, TLS is the most widely deployed and used crypto protocol in 
large part because the set of algorithms that MUST be supported to 
ensure very wide interoperability is very small, despite the fact 
that many algorithms have been defined to use with TLS.

For S/MIME and OPGP there is a requirement that, ultimately, the 
receiver has some way to verify the cert associated with the sender. 
However, it is common for senders to sign messages that are send to 
mailing lists where the sender has no way of knowing what algorithms 
all the receivers support. So, your analysis for this case is off the 
mark. (Your analysis is applicable to the case of encrypted e-mail, 
because the sender has to retrieve certs for all recipients first, 
and thus can determine what algorithms, they support. But, signed 
e-mail is MUCH more common than encrypted e-mail in the public 
Internet.)

I understand the arguments you are making, and I agree that there are 
differences between protocols that may be used in closed communities 
vs. ones that are intended to have global scope, like DNSSEC. But, I 
think the argument I made is valid.

My point is that it is unreasonable to require every DNSSEC 
implementation to support every public key signature and hash 
algorithm that anybody chooses to register. This is a classic case of 
what economists call externalization of costs. By calling for such 
support for any national algorithm suite (or any algorithms that 
might be put forth and which are not widely employed), one 
establishes a bad precedent. Rather it makes sense to have a very 
limited number of algorithm suites that MUST (or SHOULD) be 
implemented. My recommendation is to limit mandated (MUST or SHOULD) 
support to just two: current and next.

BTW, we have had this discussion in SIDR, where the RPKI has a 
similar global scope and where Vasily had made a similar request for 
recognition of GOST algorithms. So far, that WG has said no, for the 
reasons I cited in my comments and above. The current plan there is 
to go with the two suite model I described above.

Steve