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: Jakob Schlyter <[email-masked]>
Date: Tue, 11 Feb 2003 14:40:06 +0100 (CET)

> RSA/SHA1 as the only mandatory to implement algorithm.

yes.

	jakob

---

From: [email-masked]
Date: Wed, 12 Feb 2003 07:31:16 +1100

> RSA/SHA1 as the only mandatory to implement algorithm.

	One of the purposes of two manditory protocols was to ensure
	that we could always have working DNSSEC in the event that
	a way to compromise a algorithm was found.  You could then
	switch off that algorithm and still have a secure system
	while another algorithm was deployed to replace the compromised
	one.  [ Yes, named is missing the switches to turn this off
	algorithms at runtime.  This will be addressed. ]

	This would remove the fallback solution and require massive
	quick redeployment of dnssec suites in the event of a
	compromise to RSA/SHA1.

	The down side of having two manditory algorithms is that
	you should be signing with both all the time otherwise when
	one is compromised you will have whole branches being
	isolated.

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

---

From: Rob Austein <[email-masked]>
Date: Tue, 11 Feb 2003 16:10:18 -0500

> 	one is compromised you will have whole branches being

Counter argument is that having two algorithms means that one can be
attacked via a break in either 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.

---

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

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

> 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

---

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: [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: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 23:41:08 -0500

> 	to recover from single points of failure.

Fine, then let's define 10 different algorithms, call them all MUST,
and require everyone to sign their zone 10 times...

Where does it end?

Seriously, you're over-engineering a solution to something I consider
a non-problem.  And honestly I think that Mr. Bellovin or Mr. Schiller
would agree with me that this is a non-problem.  The problem we want
to solve here is that DNS Resolvers, Caching Services, and Primary
Servers are slow to deploy/upgrade.  Changing the software is HARD.

However, the DATA in the DNS is _EASY_ to change...

Let's not lose sight of the forest for the trees....

-derek

---

From: [email-masked]
Date: Wed, 12 Feb 2003 16:05:24 +1100

> and require everyone to sign their zone 10 times...

	Well you only need two at any point in time to deal with a
	single failure.

> However, the DATA in the DNS is _EASY_ to change...

	No.  It's not easy.  It's easier but it's still hard.

	When it happens it is going to be hard enough just to get
	the word out to say "don't use this algorithm anymore".
	It will be MUCH harder to get the new data deployed if it
	is not deployed as part of standard procedures.

	MUCH HARDER still will be the job to roll out the new
	manditory it implement algorithm to replace the corrupted
	one.

---

From: David Blacka <[email-masked]>
Date: Wed, 12 Feb 2003 00:35:23 -0500

> and require everyone to sign their zone 10 times...

I'd like to point out that because of the way DNSSEC verifiers are defined to 
work, when you sign your zone with more than one algorithm, you become open 
to attack when *any one* of those algorithms is found weak.  Verifiers just 
ignore non-validating SIGs.

To my thinking, signing with more than one algorithm is less secure than 
signing with just one.  Or, at best, no more secure.

Honestly, I understand where Mark is coming from.  He is optimizing for the 
resolver perspective.  From the resolvers point of view, being able to just 
"turn off" the broken algorithm and then have the entire DNSSEC tree suddenly 
be secure again must be pretty attractive.  

But from the zone owner's perspective, his zone will be vulnerable until 
either he re-signs the zone or all resolvers are reconfigured to not use the 
bad algorithm.  From the zone owner's perspective the fastest way back to 
security is to resign the zone.  Who knows how long it will take for all the 
security aware resolvers to change their configurations?

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Greg Hudson <[email-masked]>
Date: 12 Feb 2003 01:41:29 -0500

On Wed, 2003-02-12 at 00:35, David Blacka wrote:
> bad algorithm.

I don't see how re-signing the zone helps.  If I can forge, say, RSA
signatures, then I can forge a signature chain all the way from the
client's pre-configured RSA public key to the domain I'm trying to
attack, whether or not the real zone data has been re-signed with a DSA
key.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 12 Feb 2003 09:37:31 +0100

> 	is not deployed as part of standard procedures.

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.

In other words: "You do not have to outrun the bear as long as you
outrun the other guy" and if RSA is compromised there are other guys
than DNS that are a much tastier game.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Kare Presttun <[email-masked]>
Date: Wed, 12 Feb 2003 12:42:02 +0100

>than DNS that are a much tastier game.
Sooo true!!

Med vennlig hilsen | Best regards,
Kåre Presttun
Tel.: +47 4100 4908
mailto:[email-masked]
http://www.presttun.org/kare/