Subject: DNSSEC / RSA / SHA-1

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 08 Apr 1999 11:14:02 -0400

Currently the DNSSEC algorithm 1 is defines as RSA/MD5.  This was
originally defined quite a while ago and used MD5 because that was
standard for IETF algorithms at the time.  But by now SHA-1 has been
around for a while and most cryptographers believe it is stronger than
MD5.  Thus it might be better to have an RSA/SHA-1 algorithm
available.  (SHA-1 also produces a longer hash than MD5 but that
doesn't make the resulting SIGs any bigger.)

Algorithm 1 is recommended to be implemented in RFC 2535.  Algorithm
3, the DSA mandatory to implement algorithm, already uses SHA-1.

It would be possible to redefine algorithm 1 to use SHA-1.  While
there is very limited deployment of DNSSEC crypto at this point, that
would not be backward compatible.  Instead I plan to write a draft
aimed at Proposed Standard that defines algorithm 5 to be RSA/SHA-1
but I though I would ask for WG feedback first. (I'm sending this to
namedroppers due to the amalgamation of the DNSIND and DNSSEC WGs.)

Another possibility would be to define algorithm 5 to be RSA with an
additional field to select the hash algorithm but the current thinking
is mostly against such orthogonality because of potential substitution
or cross product weaknesses, etc., and go for specifying crypto
suites.

It should be noted that the key stored in either an algorithm 1 or the
proposed algorithm 5 KEY RR is just an RSA public key which other code
could use with whatever hash algorithm it wanted.  It is just that for
DNSSEC use, that is, the calculation and verification of SIG RRs, the
standard would require use of MD5 for algorithm 1 and SHA-1 for
algorithm 5.

Any comments?

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA

---

From: John Gilmore <[email-masked]>
Date: Thu, 08 Apr 1999 15:17:02 -0700

We should stop fiddling with paper specs in DNSSEC, deploy the
*^&%&^$@# thing and get some real operational experience, and THEN fix
what needs to be fixed to make it scale worldwide.

	John

---

From: Bill Manning <[email-masked]>
Date: Thu, 8 Apr 1999 16:13:06 -0700 (PDT)

> what needs to be fixed to make it scale worldwide.

bits are getting there... the ip6.int zone should pop out within the
week.

--bill

---

From: Bill Manning <[email-masked]>
Date: Thu, 8 Apr 1999 19:24:20 -0700 (PDT)

>> *^&%&^$@# thing
> send real == scalable code
> 
> randy

scale to what measures?  last time I checked, the Internet was basically
an iterative process.  propose, test, refine/renovate/remove & back to
step one.

--bill

---

From: Randy Bush <[email-masked]>
Date: Thu, 8 Apr 1999 21:30:27 -0700 (PDT)

> You seem to be arguing that we shouldn't bother trying to figure out the
> above unless we have a full implementation.

no.  my point was that mr. gilmore screaming "deploy" as if we could, and
suggesting that designers should go to sleep for a year until we do, is not
very helpful to the ietf process.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 8 Apr 1999 21:22:03 -0700 (PDT)

> an iterative process.  propose, test, refine/renovate/remove & back to

that it can be used to secure a significant part of the dns traffic on the
net.  i.e. that it is not a toy that takes very serioys warnings from the
vendor.

as far as i can remember, drc said beta in october.  so that seems to be
when we have a first hope of *^&%&^$@#ing deploying the thing.  or maybe
stuart kwan's or another will be available earlier.

randy

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 08 Apr 1999 20:58:33 -0700

> send real == scalable code

Right, just like SNMPv2 had real code... err, oops.  Nevermind  :-)

More seriously, I personally would very much like to see limited
deployment of DNSSEC even if it is not "real" or "scalable" so we can
figure out a) if it will even work b) the possible operational
implications and c) what policies and procedures are necessary to
actually deploy DNSSEC.

You seem to be arguing that we shouldn't bother trying to figure out the
above unless we have a full implementation.  I always thought getting
field experience useful in helping to refine protocols and/or
implementations.  But maybe that's just me -- I'm not smart enough to
figure everything out beforehand.

Regards,
-drc

---

From: Bill Manning <[email-masked]>
Date: Thu, 8 Apr 1999 21:27:46 -0700 (PDT)

> stuart kwan's or another will be available earlier.

hum.  the 8.2 release has the code & a signer.  from what I've heard
drc indicated 9.0 betas later this year, which is a very different
animal.

--bill

---

From: Bill Manning <[email-masked]>
Date: Thu, 8 Apr 1999 21:31:53 -0700 (PDT)

> stuart kwan's or another will be available earlier.

pressed enter too soon.  I'll note that the 8.2 release is the second
pass at a DNSSEC code base.  TIS had one a few years back.  I expect
9.0 (and other members of the genepool) will have similar capabilities.
I don't expect them to be the last either.  It looks like an iterative
process to me.  Scalability will come.

--bill

---

From: Randy Bush <[email-masked]>
Date: Thu, 8 Apr 1999 18:28:50 -0700 (PDT)

randy

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 09 Apr 1999 11:22:49 -0400

>doesn't make the resulting SIGs any bigger.)

While I agree with you on that yes SHA-1 is "more secure", for operational
reasons I do not think we should do this right now.
In about 2 years when we have operational deployment and no patent issues
to deal with, then is a good time to revisit this issue. 

Translation: I do not want to change the code, and I do not want to talk to
any export control lawyers for the rest of this year !!!!!

>there is very limited deployment of DNSSEC crypto at this point, that

NO NO NO NO NO

>namedroppers due to the amalgamation of the DNSIND and DNSSEC WGs.)

New number is REQUIRED

>or cross product weaknesses, etc., and go for specifying crypto

NO NO NO NO NO NO no escape hatches we have 250+ values, 
number of known strong hash algorithms < 10
Number of known strong public key algorithms < 10 

Thus there is no real reason why we will run out of number space. 
The time to play games like this was when YOU defined the protocol in the
first place instead of using 1 byte for algorithm you could have used 2 bytes
in the signature one for the PK algorithm and one for the hash algorithm.

	Olafur

---

From: "David R. Conrad" <[email-masked]>
Date: Fri, 09 Apr 1999 11:07:47 -0700

Randy,

> my point was that mr. gilmore screaming "deploy" as if we could, 

I believe the point John and others is trying to make is that we _can_
deploy DNSSEC in a limited fashion using a code base that, while it
cannot test all aspects of DNSSEC, can test significant portions plus
begin to establish the operational procedures necessary for full
deployment.

> and

I must admit I would have thought an initial deployment of DNSSEC would
be helpful to the IETF process, particularly by giving protocol
designers actual operational issues (assuming such are encountered) to
keep them awake.

Regards,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Fri, 09 Apr 1999 10:53:43 -0700

Hi,

>> net.  

Do you really feel the protocol (never mind the implementation) has had
enough implementer and operator eyeballs looking at it to risk deploying
it on a wide scale?  I don't.  Wouldn't it be better to do a limited
deployment to shake out the protocol keeping in mind the one-and-only
existing implementation has limitations?

>> as far as i can remember, drc said beta in october.  

BIND version 9 will be going into beta in October.  8.2 has a partial
DNSSEC implementation including:

- all of the DNSSEC records (SIG, NXT, KEY, CERT, TSIG)
- all DNSSEC crypto algorithms (RSA & DSA for SIG, HMAC-MD5 for TSIG)
- sending SIGs with data,
- sending KEYs as additional data
- verifying data on load and when received over the wire, if the key is
  present and considered secure.
- TSIG transaction/request signatures on all message types
- signing zones using the contributed signer
- generating keys

What it doesn't do is:
- actively go out and look for KEYs if it finds signed data
- attempt to verify data when KEYs arrive
- obey the ad and cd bits
- do any NXT processing (that is, return NXT on failures)

In addition, given the lack of EDNS0 support in BIND 8.2, you'll get a
fallback to TCP so you do not want to deploy this on a server that gets
a high rate of queries per second (unless you have a kernel tuned to
handle huge numbers of sort-lived TCP sessions).

>> or maybe

I personally would be ecstatic if there was another DNSSEC
implementation 'cause it'd be really nice to compare notes.  However, I
have not heard of any.

> drc indicated 9.0 betas later this year, which is a very different

Yes.  BIND version 9 is a full DNSSEC implementation with full EDNS0
support.

Regards,
-drc

---

From: Randy Bush <[email-masked]>
Date: Fri, 9 Apr 1999 22:19:06 -0700 (PDT)

>> and suggesting that designers should go to sleep for a year until we do,
>> is not very helpful to the ietf process.
> I must admit I would have thought an initial deployment of DNSSEC would be
> helpful to the IETF process, particularly by giving protocol designers
> actual operational issues (assuming such are encountered) to keep them
> awake.

no question.  but it has been observed that those areas where deployment is
embarrassingly slow have this penchant for telling everybody else that they
should stop all design while development/deployment takes a few more years
to catch up.  and the whining seems to be inversely proportional to the rate
of development/deployment.

along the vein of progress, i vaguely think think that edns0 made it through
the iesg this week.  truth is thomas will remember better than i, as he is
our ad and i was concentrating on other i-ds.

randy

---

From: John Gilmore <[email-masked]>
Date: Tue, 27 Apr 1999 01:14:02 -0700

> very helpful to the ietf process.

Actually my suggestion to try deploying DNSSEC is so that we can get
some actual feedback into the IETF process after trying to use it in
real life.  So far all the feedback has been academic in nature ("I
like it better this way" as opposed to "I tried it this way and it
didn't work, so I tried it that way and it did.")

I'm still an IETF newbie, but I thought this emphasis on the practical
was what distinguished IETF from, say, ANSI.

	John