Subject: Re: [dnsext] GOST algorithms in DNSSEC

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 3 Dec 2009 16:24:52 -0600 (GMT-06:00)

Stephen and all,

  Quite frankly it is my position and our practice sense
implimenting DNSSEC several years ago that limiting algorithms
in any fashion is unwise and can lead to less than adaquate
DNS security accordingly.

-----Original Message-----
>From: Stephen Kent <[email-masked]>
>Sent: Dec 3, 2009 11:57 AM
>To: [email-masked]
>Cc: Stephen Kent <[email-masked]>
>Subject: [dnsext] GOST algorithms in DNSSEC
>
>[ Moderators note: Post was moderated, either because it was posted by
>   a non-subscriber, or because it was over 20K.  
>   With the massive amount of spam, it is easy to miss and therefore 
>   delete relevant posts by non-subscribers. 
>   Please fix your subscription addresses. ]
>
>Folks,
>
>I am opposed to assigning algorithm identifier values to the GOST 
>algorithms, until the WG has solved the alg ID space problem. I 
>believe Paul Hoffman suggested this in Hiroshima.
>
>My reasoning is that we need to provide a clear distinction between:
>
>	- algorithms that are MUSTs, i.e.,  mandatory to implement in 
>all DNS resolvers and zone signers
>
>	- algorithms that are MAYs
>
>Because we have limited space for algorithm IDs under the current 
>design, I think it appropriate to agree upon a scheme that enables 
>expansion of the ID space first, and then to assign IDs for these 
>these two categories of algorithms.  One might choose to assign the 
>two classes of algorithms to two different ID spaces, to reinforce 
>this notion, although that may not be necessary.
>
>If alg ID space were not in short supply, this would not be an issue. 
>In other security protocol contexts with which I am familiar, we have 
>usually avoided this thorny issue. This is because we have adopted 
>alg ID schemes that have offer very large (essentially unlimited) 
>space, e.g., OIDs. Unfortunately, this is not the case for DNSSEC, 
>and thus I believe that it is prudent to proceed with caution.
>
>Steve
>

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 17:14:01 -0500

>DNS security accordingly.

Can you explain your statement a bit more? I can imagine two 
different contexts that might motivate it, and want to know which one 
you have in mind (or if there is some other motivation behind your 
statement).

In the public Internet, DNSSEC will yield the greatest benefit if 
every user is able to verify every signed record.  This suggests that 
one should avoid a proliferation of algorithms, since proliferation 
imposes burdens on user software. Ideally, one would have two sets of 
algorithms, one current and one "next" to enable a transition as 
cryptanalysis motivates such transitions.

If, you're suggesting that closed environments ought to be able to 
use whatever algorithms they wish, I agree. There are two private 
algorithm IDs defined in 4034, with different ways of identifying 
such algorithms. This allows private use algorithm assignment

We ought to be able to assign a code point to anyone who requests one 
(with suitable IETF references to the algorithms). However, it was my 
understanding that the current space for such code points is limited 
(otyer than  the private alg ID space). That motivates defining a way 
to extend the alg ID space, an activity that I understand is already 
underway. I was suggesting that we impose a moratorium on assigning 
any new alg IDs (for GOST and the slew of ECDSA and SHA-xxx requests) 
until the new code space format and conventions are agreed upon, 
including the criteria for assigning algs to the current space vs. 
extended spaces.

Steve