Subject: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 24 Sep 2003 13:16:31 +0200

I want to point attention to draft-ietf-dnsext-dnssec-records-04 section 1.3.1

1.3.1 Open Technical Issues

   The cryptographic algorithm types (Appendix A) requires input from
   the working group.  The DSA algorithm was moved to OPTIONAL.  This
   had strong consensus in workshops and various discussions and a
   separate internet draft solely to move DSA from MANDATORY to OPTIONAL
   seemed excessive.  This draft solicits input on that proposed change.

Please speak for or against this. 

Default action will be to accept DSA moved to OPTIONAL as working-group concensus. 

Review of this I-D and the dnssec-intro document is appreciated. 

-- Olaf Kolkman
   DNSEXT Co-Chair

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Wed, 24 Sep 2003 08:27:42 -0700 (PDT)

> On Wed, 24 Sep 2003, Olaf M. Kolkman wrote:
> 
> yes, I think we should move DSA to optional.
> 
> 	jakob
> 

	based on several years of operational experience, DSA to optional
	seems like a good idea.

--bill

---

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 25 Sep 2003 13:35:05 -0400

Jim Reid wrote:
> I agree with Michael. It would be prudent to have a second algorithm
> as a safety net. No SPoFs and all that. Even though a vulnerability in
> RSA looks unlikely and DNSSEC wouldn't be top of the list of things to
> worry about if that happened.
> 
> I'd prefer the draft to use 2119 language: MUST, SHOULD, MAY and so
> on. OPTIONAL is too fluffy.
> 
> Count this as another vote for a SHOULD for DSA.

I agree with Michael R. and Jim R. in that I believe it is acceptable
to move DSA to an "optional to implement" status, but that it is
appropriate to use RFC 2119 terminology (in this case a SHOULD,
to indicate that it's still a Really Good Idea to implement both
algorithms).  One way to summarize this proposed change:

  Algorithm:
    RSA	- Mandatory  (MUST be implemented)
    DSA	- Optional   (SHOULD be implemented)

  --Rip

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 25 Sep 2003 14:14:44 -0700

There is a security issue with DSA. It requires a random number to be
generated for each signature. If the random number used in a signature can
ever be guessed the private key can be recovered.

This means that implementations of DSA need to have really good
implementation to avoid a serous compromise. 

I think that should accept is reasonable but not should support.

http://www.lucent.com/press/0201/010205.bla.html

> -----Original Message-----
> From: Loomis, Rip [mailto:[email-masked]]
> Sent: Thursday, September 25, 2003 1:35 PM
> To: [email-masked]
> Subject: RE: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional 
> 
> 
> Jim Reid wrote:

---

From: Miek Gieben <[email-masked]>
Date: Fri, 26 Sep 2003 00:01:09 +0200

[On 25 Sep, @19:35, Loomis, wrote in "RE: DNSSEC-RECORDS ISSUE: DSA  ..."]
>     DSA	- Optional   (SHOULD be implemented)

I support this too,

    grtz  Miek

--
"So long and thanks for all the fish" -- Hitchhikers Guide to the Galaxy

---

From: [email-masked]
Date: Fri, 26 Sep 2003 08:23:34 -0400 (EDT)

On Thu, 25 Sep 2003, Michael Richardson wrote:
> 
>   1) SHOULD means, "unless you have a very convincing reason not to".

In this case, following the suggestion is practically pointless, and 
therefore shouldn't be a SHOULD. If the only concern is fear of legal 
silliness over RSA, then forget about RSA, and mandate DSA up front.

>   2) If we don't suggest that people support at least two algorithms, then
>      the odds of them supporting three when we need a third is zilch.

If you make two a SHOULD, the odds that people will spontaneously support
three is zilch.

Regards,
Len.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Sep 2003 06:21:17 -0700

>   I'm not sure if ElGamal is really different enough. Maybe 
> there are no such algorithms. 

Well as Dan points out fast factoring methods can be retargetted to be
discrete log problems.

I guess we could have some people go and define a DSA256 by taking the
principles of DSA and extending to a bigger key and a bigger hash algorithm.
It is a heck of a lot of work to do right.

I am sure this is not the place to do that.

	Phill

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Sep 2003 16:29:47 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "lbudney" == lbudney  <[email-masked]> writes:

    lbudney> In this case, following the suggestion is practically pointless,
    lbudney> and therefore shouldn't be a SHOULD. If the only concern is fear
    lbudney> of legal silliness over RSA, then forget about RSA, and mandate
    lbudney> DSA up front.

  No, the concern is code space and programmer time.
  I'm not thinking legal concerns at all. The only time someone might
consider dropping DSA is because they ran out of firmware space, *AND* they
are operating in some limited environment. 

    >> 2) If we don't suggest that people support at least two algorithms,
    >> then the odds of them supporting three when we need a third is zilch.

    lbudney> If you make two a SHOULD, the odds that people will
    lbudney> spontaneously support three is zilch.

  No, having said that there are two algroithms, the code path starts
to look like:

   switch(algo) {
   case RSA:
	/* do stuff */
	break;

   case DSA:
	/* do stuff */
	break;

   default:
	/* complain */
   }

  Adding the third case is much easier at that point.
  On the other hand, if you start with a single MUST, and the other one
is effectively, "do not bother", then if you are lucky, it turns into:
      assert(algo == RSA);

  if you are not, the programmer just doesn't check.

  I've been there. I've managed ID10T programmers. I seldom get the authority
to fire them, alas.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: [email-masked]
Date: Fri, 26 Sep 2003 17:10:44 -0400 (EDT)

On Fri, 26 Sep 2003, Michael Richardson wrote:
>> If the only concern is fear of legal silliness over RSA, then forget
>> about RSA, and mandate DSA up front.
> 

Then why waste their time telling them they "should" implement two 
protocols, when the result is a decrease in security anyway?

> The only time someone might consider dropping DSA is because they ran
> out of firmware space, *AND* they are operating in some limited
> environment.

Surely that isn't the "only" time.

>> If you make two a SHOULD, the odds that people will spontaneously
>> support three is zilch.
> 
> No, having said that there are two algroithms, [coders will implement a
> switch statement on encryption type, and] Adding the third case is much
> easier at that point.

Is it just me, or is it a bit bizarre to issue a declaration in the 
standard which is intended to drive developers toward a particular 
low-level implementation you think they should use?

> I've been there. I've managed ID10T programmers. I seldom get the
> authority to fire them, alas.

Most programmers are idiots. The goal in writing this standard is not to 
somehow trick them into producing competent work. The task isn't possible, 
and the side effect of the failed attempt will be cruft in the standard.

Regards,
Len.