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: Donald Eastlake 3rd <[email-masked]>
Date: Wed, 24 Sep 2003 09:43:03 -0400 (EDT)

I'm in favor of the change.

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
 Milford, MA 01757 USA                   [email-masked]

On Wed, 24 Sep 2003, Olaf M. Kolkman wrote:

> Date: Wed, 24 Sep 2003 13:16:31 +0200
> From: Olaf M. Kolkman <[email-masked]>
> To: [email-masked]
> Subject: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional
> 
>

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 24 Sep 2003 16:33:00 +0200 (CEST)

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

yes, I think we should move DSA to optional.

	jakob

---

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

> yes, I think we should move DSA to optional.

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

--bill

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Sep 2003 09:33:05 -0400

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

The words MANDATORY and OPTIONAL are confusing to me.

It says:
   A DNSSEC aware resolver or name server MUST implement all MANDATORY
   algorithms.

So, I know that MANDATORY is equivalent to 2119's MUST.
Is "OPTIONAL" equal to "SHOULD" or "MAY"

I feel uncomfortable with DSA as "MAY".
I would feel okay with DSA as "SHOULD".

If we had a documented third alternative, I might feel okay if it said
you MUST implement at least two algorithms. Of course, that wouldn't
guarantee that we could "failover" to the other algorithm, since there
wouldn't a unique choice of what to failover to.

You may want to look at draft-ietf-ipsec-ikev2-algorithms-04.txt for
how IPsec is handling this topic.

]      Out and about in Ottawa.    hmmm... beer.                |  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: Jim Reid <[email-masked]>
Date: Wed, 24 Sep 2003 20:51:36 +0100

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.

---

From: Fearghas McKay <[email-masked]>
Date: Wed, 24 Sep 2003 23:03:29 +0200

>Count this as another vote for a SHOULD for DSA.

Count this as a another vote for SHOULD.

Thanks

	f

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Sep 2003 01:29:00 -0000

Jim Reid writes:
> It would be prudent to have a second algorithm as a safety net. No
> SPoFs and all that.

Let me see if I understand how you imagine this ``safety net'' working.

Users sign their records with, say, 768-bit RSA. Someone announces a
768-bit RSA factorization. Users decide to change their keys to, say,
768-bit DSA. Right?

If so, you've now created massive verification failures. Verifiers that
don't support DSA will automatically disable all security, allowing the
records to be forged by any sniffing (or persistent blind) attacker at
far less cost than breaking another 768-bit RSA key.

In short, users are _losing_ security in this situation, unless DSA is
MANDATORY. It doesn't make sense to have an optional backup algorithm.
The only reasonable possibilities are mandatory DSA or no DSA at all.
This seems to be yet another example of ``SHOULD'' meaning ``The authors
of this document didn't think through the protocol.''

Furthermore---I'll put on my cryptographer's hat for a moment---current
methods are going to break 768-bit DSA not long after they break 768-bit
RSA. Modern ``combination-of-congruence'' factoring methods can be
adapted to compute discrete logarithms at almost the same speed. Using
both RSA and DSA is a waste of implementor time that could be better
used for, say, implementing RSA signature compression.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Jim Reid <[email-masked]>
Date: Fri, 26 Sep 2003 04:02:36 +0100

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    >> It would be prudent to have a second algorithm as a safety
    >> net. No SPoFs and all that.

    djb> Let me see if I understand how you imagine this ``safety
    djb> net'' working.

Your understanding and imagination are wrong. The safety net I have in
mind has nothing to do with key lengths. Or having "extra security" by
signing the same data with a second key. It's a safety net for the
protocol by having a second ALGORITHM, just in case there's a problem
with the mandatory one. That problem might be cryptographic though I
very much doubt that. It could be a legal problem. For instance
someone somewhere passes an idiot law to prohibit RSA or its export.
That's happened before. Perhaps lawyers for RSA Inc (or whatever
they're calling themselves today) manage to find some sleazy way to
extract huge licence fees or revive expired patent rights so that RSA
becomes effectively unusable. These scenarios aren't beyond the bounds
of possibility. We've all seen the absurdities an army of well-funded
lawyers can achieve. Suppose RSA has to be dropped for some reason
after there's a non-trivial amount of DNSSEC deployment. Wouldn't it
be helpful to be able to switch over to an alternate algorithm that's
already implemented in the name servers and resolvers until a new one
can be chosen and rolled out? IMO the protocol needs a safety net to
guard against those kinds of SPoFs.

Now whether that second algorithm should be DSA or something else is
another debate. I'm happy for the cryptographers to decide that, just
as long as all the DNSSEC eggs don't end up in the one RSA basket.

And anyway, what do you care? You're not going to implement DNSSEC or
interoperate with it. Or have you finally seen the light?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Sep 2003 23:04:50 -0400

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

>>>>> "D" == D J Bernstein <[email-masked]> writes:
    D> Furthermore---I'll put on my cryptographer's hat for a
    D> moment---current methods are going to break 768-bit DSA not long after
    D> they break 768-bit RSA. Modern ``combination-of-congruence'' factoring
    D> methods can be adapted to compute discrete logarithms at almost the
    D> same speed. Using both RSA and DSA is a waste of implementor time that

  So, you are right. There are two things to consider, however:

  1) SHOULD means, "unless you have a very convincing reason not to".
     This is why I asked what "OPTIONAL" means.
     SHOULD does not mean "if you feel like it"

  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.

  I'd like to think that we'll standardize some other algorithm than DSA,
ideally one with very different properties such that they aren't broken by
the same miracle.
  I'm not sure if ElGamal is really different enough. Maybe there are no such
algorithms. 

] 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: "D. J. Bernstein" <[email-masked]>
Date: 26 Sep 2003 05:04:47 -0000

Jim Reid writes:
> interoperate with it.

What http://cr.yp.to/djbdns/forgery.html actually says is ``I'm not
going to bother implementing DNSSEC until I see (1) a stable, sensible
DNSSEC protocol and (2) a detailed, concrete, credible plan for central
DNSSEC deployment.''

I'm disappointed that in ten years you've failed to achieve #1 and #2;
I'm certainly not going to hold up my own DNS security projects waiting
for DNSSEC; but I'm continuing to watch what happens with DNSSEC.

> It's a safety net for the protocol by having a second ALGORITHM

How exactly does anyone benefit from ``having'' a second algorithm?

Let's look at your revised nightmare scenario. Lots of users sign their
records with RSA. Suddenly the RSA company threatens them with lawsuits.
Users decide to change to DSA.

This produces a massive security hole, exactly as I explained before---
unless DSA was already _mandatory_, which is not what you're advocating.

Let's take another ``single point of failure'' in your terminology:
HTTP. Presumably you think that web servers ``SHOULD implement FTP,''
just in case someone claims patent rights over HTTP. What you're failing
to explain is WHY THIS HELPS. How does an _optional_ backup mechanism
prevent the problems that you're talking about?

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 26 Sep 2003 09:45:05 +0200

On 26 Sep 2003 05:04:47 -0000
"D. J. Bernstein" <[email-masked]> wrote:

> DNSSEC protocol

draft-ietf-dnsext-dnssec-records-04, draft-ietf-dnsext-dnssec-intro-04
and forthcoming draft-ietf-dnsext-proto-03 (in a week or two) contain
the specifications with all the issues that came up during the rewrite
resolved, there are a number of minor textual issues and things that
may need a little rewording but the core is solid. A review of those
document is appreciated.  WGLC may be a weeks from now rather than
months.

-- Olaf

PS. With respect to #2, you are right, nothing there yet. It needs
work but lets first get protocol.

---

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

On Fri, 26 Sep 2003, Jim Reid wrote:
> mind...It's a safety net for the protocol by having a second ALGORITHM,
> just in case there's a problem with the mandatory one.

The objection that remains valid: if the protocol allows multiple
algorithms without making support for all of them mandatory, then one of
two things will happen. When an algorithm is chosen that is unsupported by
the other party, either all data must be rejected, or cryptographic
signing must be ignored. The former leads to DoS, and the latter leads to
obvious spoofing attacks.

Bruce Schneier has written extensively on this issue. Not that Dan needs 
the backup, being a cryptologist in his own right.

The only way to support multiple protocols is to allow the data's owner to 
select the protocol of his choice, and require clients to accept the 
choice and support whatever protocol the owner mandates. Any other 
approach results in one of: DoS; spoofing; or forced use of weak keys.

Regards,
Len.

---

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

>   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.

>      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: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 26 Sep 2003 15:40:01 +0200

> obvious spoofing attacks.

I agree with your analysis. 

But,

Regardless of MUST or SHOULD for DSA there may be a point when we need
a 3rd algorithm. The underlying requirement is that it should be
possible to introduce a new algorithm without creating attacks on
resolvers that _do_ implement the new algorithm. (That has been
discussed at length and is IMHO solved in another thread, see the
archive on the Q2 bis issue).

From an operational point of view it is IMHO acceptable for resolvers
to ignore cryptographic signing for algorithms that are not
understood. In the end it is the choice of the resolving end if it
wants to live in a secured world or not; if the new algorithm is
needed than you go to your supplier and have the new algorithm
implemented. 

Currently that operational model seems to work since most resolvers
understand nor RSA or DSA and therefore ignore cryptographic
signing :-).

I am agnosic about MUST/SHOULD on the support of the current
algorithms. I rather see the specification, and the applications based
on it, written in such a way that another algorithm can be made
mandatory later. I read the documents to reflect that requirement 
(Do others?).

As an asside: operationally it is more difficult to get rid of the old 
algorithm than to introduce a new one; think trust anchors.

-- Olaf
   namedroppers participant

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

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.

---

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.