Subject: Q2: crypto algorithm requirements for DNSSEC

From: "Scott Rose" <[email-masked]>
Date: Tue, 11 Feb 2003 07:40:23 -0500

There have been previous updates to the requirement levels of the
cryptographic algorithms for DNSSEC (RFC 3110 updating RFC2535 for example).
There has been previous talk on this list regarding dropping DSA as a
mandatory to implement algorithm.  Instead of writing a whole RFC just to
propose making DSA optional and RSA/SHA1 the only required algorithm, it
would be nice to seek consensus here.

In other words, the new algorithm table from 2535 and 3110 would look like:

code            name
0                reserved
1                RSA/MD5        NOT RECOMMENDED
2                D-H                  OPTIONAL
3                DSA                 OPTIONAL
4                ECC(reserved)    OPTIONAL
5                RSA/SHA1        REQUIRED
6-251         available for assignment
252            indirect                OPTIONAL
253            private
254            private
255            reserved

Q:  Is the change of DSA to OPTIONAL  acceptable?  That will leave only
RSA/SHA1 as the only mandatory to implement algorithm.

--
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: "Loomis, Rip" <[email-masked]>
Date: Tue, 11 Feb 2003 15:32:45 -0500

> mandatory to implement algorithm.  

My summary of those previous discussions, testing of which I'm
aware, and my own thoughts:
  - RSA was patented at the time of the original DNSSEC work, so
    a patent-free alternative was desired.  RSA can now be implemented
    without patent encumbrances--that doesn't mean that DSA isn't
    useful as an alternative.
  - DSA has significantly lower performance in all current implementations
    of which I'm aware.  Some of that is related to characteristics of
    DSA, in that the "sign once, verify many" model works better with
    an algorithm like RSA (verification time is << signing time) than it
    does with a balanced algorithm like DSA (verification time is similar
    to signing time).  That means DSA is currently less useful than RSA
    for most real-world applications, but doesn't mean it's useless.
  - If at some point there's a significant cryptographic problem found
    with RSA, It Would Be Nice if there were an alternative already
    deployed.  Then again, if there's a major new cryptographic attack
    found to which RSA is vulnerable, DSA might be vulnerable as well.
  - If we require one less algorithm to be implemented in the software,
    then it might make it easier on implementers.  That argument seems
    to me not to carry much weight--there are already RSA and DSA crypto
    implementations out there and I doubt any DNS software author will
    be writing their own.  

> Q:  Is the change of DSA to OPTIONAL  acceptable?  That will 
> leave only RSA/SHA1 as the only mandatory to implement algorithm.

I never saw a convincing argument, given the above items, as to why this
was a *useful* change.  Whose time are we really saving by making this
change?  DSA might not be incredibly useful today, but I guess I don't
see why it's useful to "unspecify" it when it's already documented and
specified.  Yes, I just tried to look through my archives and notes to
see if I missed the convincing argument.

If I've missed some past convincing argument, or if I've screwed up
anything in my summary above, I'm sure someone will re-calibrate me.
If the question is "Could I *live* with this change?" then the answer
would be Yes.  I'm just not sure why the change is desired.

  --Rip

---

From: [email-masked]
Date: Wed, 12 Feb 2003 10:00:21 +1100

> Counter argument is that having two algorithms means that one can be
> attacked via a break in either algorithm.

	That is why the use of a particular algorithm MUST be
	selectable at runtime both in the signer and resolver.  We
	already have had to withdraw one algorithm.

> So, while I understand the desire to have a fallback strategy, I'm not
> sure that we really have one whether DSA is mandatory or not.

	Well the choices are:
	* Immediate replacement of all resolvers. 
	* Immediate disabling of a algorithm and gradual replacement
	  of all resolvers.

	You will get *much* higher success with the second vs the first.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 18:29:37 -0500

There is a difference between "MUST implement" and "MUST use".  We
could always specify "must implement" for two algorithms, but provide
language that suggests that you should use one and should not use the
other.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 18:33:52 -0500

> see if I missed the convincing argument.

The only argument I've seen (note: I'm repeating it here to answer
your question, not because I necessarily agree with it) is that is
embedded devices (like an IP Phone that does its own DNSSec
verfication) you don't want to have to implement more than you really
need.  A "must" algorithm that is never used is just a lot of wasted
bits in a very restricted space.

Note that I'm not convinced this is a compelling argument, but it's
the best one I've heard so far.

> would be Yes.  I'm just not sure why the change is desired.

See my previous mail on "must implement" v "must use".

-derek

---

From: [email-masked]
Date: Wed, 12 Feb 2003 11:36:08 +1100

> language that suggests that you should use one and should not use the

	The problem is that if you don't sign with both you can't
	easily withdraw one of them when you need to.  The resolver
	can protect itself if both signatures are there.  It can
	simple choose to ignore one of them.  If they are both not
	there then it doesn't get this choice and you will get dead
	branchs as a result.

	Manditory to implement also applies to signing.  You havn't
	implemented if you are not using it.

	Mark

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 21:25:35 -0500

> 	there then it doesn't get this choice and you will get dead

So you re-sign your zone.  You have to re-sign it periodically
anyways, so what's the big deal?  Why have twice the data and perform
twice the work on the miniscule chance that one of the algorithms will
be broken during the time your signatures are valid?

>From a security viewpoint, you want the code deployed to allow you to
quickly move from one algorithm to another -- but that does *NOT* mean
that you need to use (or WANT to use) both algorithms for all your
data all the time.

> 	implemented if you are not using it.

I completely disagree.  You can implement something but not use it.

-derek

---

From: [email-masked]
Date: Wed, 12 Feb 2003 13:50:51 +1100

> be broken during the time your signatures are valid?

	It's not just re-signing the zone.  It's generating a new key,
	passing it to the parent, waiting for the DS to be published.
	(I would love to see how well Verisign copes with 10% of COM
	trying to get new DS records generated simultaniously)
	It's waiting for the majority of sites to do this before you
	can disable the vulnerable algorithm in your resolvers.  

	If the keys and sigs are already deployed all you need to
	do is disable the algorithm.

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 23:09:53 -0500

This is an operational problem, not an implementation problem.  Also,
I HIGHLY doubt this situation will occur (if it occurs at all).
Besides, if it does I think we'll have bigger problems than key
rollovers.

There is a time and a place to worry about eventualities.  This is not
one of them.

Besides, what do you do if both RSA and DSA are broken together?  Or
what if both MD5 and SHA-1 are broken together?  You can't forsee all
eventualities...  So you go with what you have and leave room in the
protocol for changing it later.  It does NOT mean that you double or
triple all the data because there is a chance that 10 or 20 years from
now someone might make a startling discovery.

-derek

---

From: [email-masked]
Date: Wed, 12 Feb 2003 15:28:45 +1100

> Besides, if it does I think we'll have bigger problems than key

	It doesn't require key rollover.  It involves disabling a
	algorithm.  This can be done in the resolver without having
	to change what is being served provide both algorithms are
	used.  Keeping the DNS working through such a event will
	very much speedup the recovery from such a event.
 
> There is a time and a place to worry about eventualities.  This is not

	This is exactly the time when we should be worring about
	this.  We are making decisions now which affect the ability
	to recover from failures like this.
 
> now someone might make a startling discovery.

	No you can't forsee all eventualities.  You can however plan
	to recover from single points of failure.

	Mark

---

From: "Loomis, Rip" <[email-masked]>
Date: Wed, 12 Feb 2003 09:27:14 -0500

(Replying to several e-mails in the thread within one, so bear with
me please...)

> bits in a very restricted space.

Okay, that's at least a reasonable argument.  It doesn't, to me,
imply that it's a significant overall advantage to anyone if we now
de-specify DSA.

> My over-engineering-flag is raised as well; If RSA get's compromised
> the DNS is the least of my worries... If RSA get's compromised I can
> live with an unsecured DNS tree... just as I can live with it today.

If RSA gets compromised, DSA is not affected by the compromise, and DSA
is implemented in compiled/embedded software, then the process of
shifting everyone over to DSA for DNSSEC might be measured in days or
weeks.  If RSA is compromised and there is no alternate algorithm 
implemented in compiled/embedded software, then the process of deploying
a new one would be measured in months or years.

I agree that we only need to be "faster than the bear" on this and
that a lot of other transactions involving cryptography will be more
appealing targets if there's a new attack on RSA...but that doesn't
mean that it's any real big savings to anyone to de-specify DSA at this
point.  (Also, if RSA *is* broken suddenly, It Would Be Nice if
there were at least one cryptographically-related system that *didn't*
need a crisis deployment of new software...)

I believe, as others have provided reasonable arguments for, that
having DSA implemented in software but recommending the use of RSA
as the primary signing algorithm is the best answer.  I would ask that
we *don't* put DSA into a SHOULD NOT USE category, because there are
folks out there who might prefer DSA to RSA for their own reasons.

I know that leaving DSA as a "must implement" algorithm smacks of
over-engineering to some folks.  Can anyone provide a convincing
argument of what the DSA-specific code actually "costs" a developer
(in terms of size of compiled code or other criteria)?  To me it
seems minor in the big scheme of things, and I think DSA should be
left in the "must implement" category.  I can live without it, but
I just haven't seen a convincing argument to remove it.

Either way, I hope we can come to a resolution quickly.  There are
a lot of other DNSSEC items that we need to finish fighting through
which I believe are more important/useful for us to spend our time
on this month...

  --Rip

---

From: "Loomis, Rip" <[email-masked]>
Date: Wed, 12 Feb 2003 12:14:08 -0500

Hello Derek--

Derek wrote:
> I don't think anyone has argued that leaving DSA as a "must implement"
> is over-engineering.  I _believe_ that the arguments have been that
> specifying that operationally you MUST USE both RSA _AND_ DSA in your
> zone is over-engineering.

Well, okay, but I don't think that was the question Scott originally

> would be nice to seek consensus here.
  [Table and other discussion elided]
> RSA/SHA1 as the only mandatory to implement algorithm.

I agree that any requirement that folks MUST USE both RSA and DSA (must
sign each record with both) is over-engineering, and actually provides
no added security while having a significant operational cost (sorry,
have to disagree with Mark A. on this one).

I don't think that's what Scott originally asked, though, which is why
I piped up in the first place.  Did I miss something?

  --Rip

---

From: "Loomis, Rip" <[email-masked]>
Date: Wed, 12 Feb 2003 14:20:08 -0500

> Rip, I don't have numbers for this specific DSA question, but after a
> decade in the embedded software market I can tell you that code space
> -always- costs for low end devices, it's just economics.

Yep.  I haven't in years, but I used to do stuff in assembler for
68HC11s and such.  I guess I was hoping that memory was now "cheap"
everywhere--not that that would really be sufficient justification to
bloat DNS code with non-useful algorithms.  But read on...

> So I have to turn the question around.  Show me that keeping DSA as
> manadatory to implement is important, and I can live with it.  But
> keeping with no strong reason to believe that it buys us anything is
> bad, because code that brings no comprehensible benefit to the
> customer has this nasty tendency to be left out of the final product
> whether the spec says it's mandatory or not, at which point we have
> interoperability problems.

OK.  I agree with a previous characterization that if RSA gets
broken suddenly/cataclysmically, then DNS won't even be *close* to
the low-hanging fruit on the vulnerability tree.  I can't come up
with a convincing enough reason, at that point, why DSA is "useful
enough" to keep as a MUST IMPLEMENT--as long as we believe that letting
embedded devices drive DNSSEC choices is a Good Idea.

Whether letting embedded devices drive DNSSEC choices really *is* a
Good Idea I leave to someone with a better big picture of such things.
From my perspective, the idea that *any* embedded device is actually
expected to implement a security-aware resolver that can do its own
signature verification is ludicrous.  It seems more likely to me
that such a device would implement IPSec to some trusted "mothership"
which could provide DNSSEC resolution, or that such a device would
blow off DNSSEC entirely, than that such a device would actually make
use of SIG and KEY records.

So my counter-question, after thinking more about this, is:
Does anyone *really* think that embedded devices should drive the choices
made in writing DNSSEC specifications?  Note that the answer to that
question has implications far beyond this single issue.

Even if we don't make the choice based solely on embedded devices,
the argument that "if we have DSA implemented already then we can
recover a signed tree faster" sounds less and less useful to me.
As a result I find myself somewhere squarely in the "undecided" category
overall--so I'll hush now.

  --Rip

---

From: Rob Austein <[email-masked]>
Date: Wed, 12 Feb 2003 14:52:17 -0500

> bloat DNS code with non-useful algorithms.  But read on...

The way it seems to work out is that, as soon as resources become
cheap enough that the current generation of widgets are no longer
resource constrained, a new generation of even cheaper widgets
redefines the meaning of "low end".  As far as I can tell, there will
always be people willing to sweat blood to try to make a go of
marketing some cool new product with profit margins that can only be
detected using an electron microscope.

> embedded devices drive DNSSEC choices is a Good Idea.

That's fair, but read on :).

> use of SIG and KEY records.

In the long run, I think it's reasonable to expect that small and
highly mobile devices will end up needing to perform their own
verification, precisely because they are mobile and may frequently
find themselves in environments where they have no usable trust
relationship with the local infrastructure.  Tunneling across an
untrusted infrastructure to get back to a home base is another
approach, but it's kinda fragile.

> question has implications far beyond this single issue.

Drive the choices?  No.  Be considered along with everything else when
making the choices?  Yes.   As I tried to say earlier, give me a
convincing argument that keeping DSA madatory would make the world a
better place and I'll shut up about this.  But, other things being
equal, please don't gratuitously drive up the cost of my toaster :).

> overall--so I'll hush now.

Fair enough.  I'll shut up now too unless somebody else wants me to
blather on about it.

---

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 13 Feb 2003 09:57:12 -0500

>>  Curiosity: How many embedded devices run a full blown resolver today?
> 
> I don't know about today, but motorola apparently announced that
> they are going to use Linux in theit mobile phones and other personal
> electronic devices: 

I like Linux and use it daily.  However, the idea that a mobile device
can run even an *embedded* version of Linux but somehow wouldn't have
room for DSA in addition to RSA seems (to me) to be ludicrous.  So I'm
not sure that this latest disclosure helps us much on figuring out
whether DSA should remain a "must implement in the software" algorithm.

If a mobile phone running Linux has any crypto support at all, I would
expect it would have all of the OpenSSL library.

  --Rip

---

From: Bill Manning <[email-masked]>
Date: Thu, 13 Feb 2003 10:30:43 -0800 (PST)

% On Thu, 13 Feb 2003, Miek Gieben wrote:
% 
% > > I wouldn't consider the resources used for signing a problem with modern
% > > hardware - people sign .com with their desktop machine within reasonable
% > > time.
% >
% > so you're asking a TLD to carry twice the load for an event which is unlikely
% > to happen soon?
% 
% yes, if we come to the conclusion that we should use two algorithms.
% 
% > And further more, we (.nl), have to explain to every domain holder in
% > .nl that signing with 2 algorithms is better than signing with 1.
% 
% if we cannot explain why to normal people, I'm not sure we should do two
% algorithms.
% 
% 
% 	jakob

back in the mists of time, we actually tested signed heirarchies with two
algorithms.  There were interesting results when trying to do validation.
as I remember, the results strengthened the argument for a single algorithm.
resolver code may have become more robust since then and the point may be
moot.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Derek Atkins <[email-masked]>
Date: 13 Feb 2003 17:48:27 -0500

[email-masked] writes:

> > signing and verifying => making deployment more straightforward. And
> > ISTR from cryptography 101 class that it's usually not a good idea to
> > encrypt or sign the same stuff with different keys or algorithms.
> 
> 	Encrypting things multiple times is a problem.
> 	Signing the same known plain text isn't.

Sure it is -- how do yo know what to do if:

        1) you only have something signed using one algorithm
        2) data is signed with multiple algorithms but one sig fails
        3) data is signed with multiple algorithms but only one sig succeeds

There is a LOT of extra policy decision that needs to happen if you go
down this road.  A lot of extra implementation, too!

-derek

---

From: [email-masked]
Date: Fri, 14 Feb 2003 10:21:07 +1100

> down this road.  A lot of extra implementation, too!

	You are missing the whole point.

	Encrypting the same plain text with multiple algorithms can
	result in one algorithm canceling out the other algorithm
	and allowing some/all of the original plain text to be
	revealed.

	This is not a issue when signing known plain text.
	
	From a cryptographic standpoint there is nothing wrong with
	signing the same thing with multiple algorithms.  You do need
	a policy (which DNSSEC has) for dealing with the case where
	not all signatures verify.

	Mark

---

From: Derek Atkins <[email-masked]>
Date: 14 Feb 2003 11:06:15 -0500

> 	You are missing the whole point.

No, I'm not.  I'm just looking at it from a different angle.

-derek