Subject: RE: Q2: crypto algorithm requirements for DNSSEC

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
posed:

> 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.
  [Table and other discussion elided]
> Q:  Is the change of DSA to OPTIONAL  acceptable?  That will leave only
> 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

--
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: "Scott Rose" <[email-masked]>
Date: Wed, 12 Feb 2003 13:33:06 -0500

Correct.  I was taking "implementation" to mean "the resolver should be
capable of verifying a SIG using algorithm X"    That is slightly different
that saying that all zone RR sets must have SIGs using multiple algorithms.

Although that point does deserve discussion:   If DSA is still  "REQUIRED",
does that mean each zone should have both a RSA/SHA1 SIG and DSA SIG for
each RR set?

I'm asking becuase I don't know what the answer should be.  I don't know if
there is a concensus what entails when there are multiple REQUIRED
algorithms.

Scott
(term nitpick - my use of "resolver" is used to mean "a security aware
resolver/verifier" in the above).

----- Original Message -----
From: "Loomis, Rip" <[email-masked]>

---

From: Miek Gieben <[email-masked]>
Date: Thu, 13 Feb 2003 10:19:29 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

[On 12 Feb, @19:33, Scott wrote in "Re: Q2: crypto algorithm requi ..."]
> there is a concensus what entails when there are multiple REQUIRED

I'm not sure what the answer should be, but I don't think a TLD will ever want
to support two different algorithms in a zone,

grtz Miek

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 13 Feb 2003 11:25:34 +0100 (MET)

On Thu, 13 Feb 2003, Miek Gieben wrote:

> I'm not sure what the answer should be, but I don't think a TLD will
> ever want to support two different algorithms in a zone,

why? due to zone size constraints? I do not agree.

	jakob

---

From: Jim Reid <[email-masked]>
Date: Thu, 13 Feb 2003 04:03:02 -0800

>>>>> "Jakob" == Jakob Schlyter <[email-masked]> writes:

    >> I'm not sure what the answer should be, but I don't think a TLD
    >> will ever want to support two different algorithms in a zone,

    Jakob> why? due to zone size constraints? I do not agree.

Well zone size is one consideration. Another would be the extra time
and resources needed to sign the same data with different algorithms.
What would be the justification for all that extra overhead? The case
for multiple algorithms is not clear, at least not to me. Having just
one algorithm would be a SPoF. OTOH it would keep things simple for
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.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 13 Feb 2003 13:09:25 +0100 (CET)

On Thu, 13 Feb 2003, Jim Reid wrote:

> Well zone size is one consideration.

maybe for .de and .com, otherwise I doubt that is a real problem.

> Another would be the extra time and resources needed to sign the same
> data with different algorithms.

I wouldn't consider the resources used for signing a problem with modern
hardware - people sign .com with their desktop machine within reasonable
time.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 13 Feb 2003 14:22:45 +0100 (CET)

On Thu, 13 Feb 2003, Miek Gieben wrote:

> 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

---

From: Miek Gieben <[email-masked]>
Date: Thu, 13 Feb 2003 14:01:03 +0100

[On 13 Feb, @13:09, Jakob wrote in "Re: Q2: crypto algorithm requi ..."]
> maybe for .de and .com, otherwise I doubt that is a real problem.

true, the size of .nl would be something of 600 MB (with 768 bits keys).
This can be handled.

so you're asking a TLD to carry twice the load for an event which is unlikely
to happen soon? 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.
I think that will be very hard to do and enforce.

grtz Miek

---

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: Paul Vixie <[email-masked]>
Date: Thu, 13 Feb 2003 21:00:25 +0000

> hardware - people sign .com with their desktop machine within reasonable

s/desktop/laptop/, but otherwise agreed.

---

From: [email-masked]
Date: Fri, 14 Feb 2003 08:34:34 +1100

> 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.
--
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: 13 Feb 2003 17:48:27 -0500

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

> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

-derek

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

---

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