Re: draft-ietf-dnsext-dnssec-gost

Stephen Kent <kent@bbn.com> Mon, 15 February 2010 14:42 UTC

Return-Path: <kent@bbn.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9F028C1AC for <ietf@core3.amsl.com>; Mon, 15 Feb 2010 06:42:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599]
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 NjeQL-cjK1CS for <ietf@core3.amsl.com>; Mon, 15 Feb 2010 06:42:53 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3BA6F3A71A6 for <ietf@ietf.org>; Mon, 15 Feb 2010 06:42:53 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Nh2BT-000DHM-Bt; Mon, 15 Feb 2010 09:44:23 -0500
Mime-Version: 1.0
Message-Id: <p06240808c79b3c5ffff5@[192.168.1.5]>
In-Reply-To: <42FABD11-2869-45FA-B82F-9956E6A18434@virtualized.org>
References: <p06240806c799d87e7406@[128.89.89.170]> <4B74646F.3080904@ogud.com> <p06240805c79b294d87a8@[192.168.1.5]> <42FABD11-2869-45FA-B82F-9956E6A18434@virtualized.org>
Date: Mon, 15 Feb 2010 09:44:16 -0500
To: David Conrad <drc@virtualized.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: draft-ietf-dnsext-dnssec-gost
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf@ietf.org, Olafur Gudmundsson <ogud@ogud.com>, iesg@iesg.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2010 14:42:54 -0000

At 8:50 AM -0800 2/12/10, David Conrad wrote:
>On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote:
>>>  Who gets to decide on what algorithms get first class status and 
>>>based on what criteria?
>>  If we look at what the CP developed in the SIDR WG for the RPKI 
>>says, the answer is the IESG
>
>So, they're going to flip a coin or what?
>
>"Who" is largely irrelevant.  The criteria is the interesting bit.

Both issues are relevant. Most of the other WGs dealing with this 
issue have been in  the secruity area and feel comfortable making 
these decisions. The IESG has been comfortable with their decisions. 
Note that change have been made, for other than technical reasons, 
e.g., initially TLS had DH 7 DSA as MUST and RSA as SHOULD, because 
of patent issues.  When the RSA patent expired, the roles were 
reversed. So the IESG has been an active participant in these 
decisions in the past.


>  >> Steve brought up "national" algorithm, but we have also 
>"personal" algorithms such as curve25519 or threefish.
>>  WGs like IPsec, TLS, and SMIME have been able to say no to 
>>"personal" algs for a long time.
>
>IPsec, TLS, and SMIME are all one-to-one.  DNSSEC (in this context) 
>is one-to-many.


Your observation is applicable to IPsec, not to S/MIME, and, for 
practical purposes, not for TLS.  An S/MIME message may be sent to 
multiple recipients, so it is not literally one-to-one. S/MIME 
accommodates algorithm diversity best for the public key algorithms 
used to encrypt the content encryption key.  It also can accommodate 
diversity for the algorithm used to sign the message, but at a higher 
cost. It does poorly if different recipients make use of different 
content encryption algorithms. TLS is nominally 1-1, but in reality, 
the vast majority of TLS use is for access to web sites that have a 
very diverse set of clients. That requires a small set of mandatory 
algorithms, to ensure interoperability.  Finally, the question  posed 
was about how have decisions on which algorithms are mandatory to 
implement have been decided in the IETF in the past. My reply 
addressed that question.

>
>Regards,
>-drc