Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-07.txt

From: [email-masked]
Date: Wed, 3 Dec 2008 08:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
	Author(s)       : J. Jansen
	Filename        : draft-ietf-dnsext-dnssec-rsasha256-07.txt
	Pages           : 9
	Date            : 2008-12-03

This document describes how to produce RSA/SHA-256 and RSA/SHA-512
DNSKEY and RRSIG resource records for use in the Domain Name System
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Dec 2008 16:06:14 +1100

For use with NSEC3 [RFC5155], the algorithm number for RSA/SHA-256
   will be {TBA2}.  The use of a different algorithm number to
   differentiate between the use of NSEC and NSEC3 is in keeping with
   the approach adopted in RFC5155.

	RFC5155 used different numbers because we *couldn't* use
	the same numbers.  That alone is not sufficient justification
	to have seperate numbers.

	The only reason to have different numbers is if the wg
	believes that there will be DNSSEC implementations in the
	future that will not support NSEC3.  Given that a number
	of TLD's intend to deploy NSEC3 I can't see any new
	implementation not including NSEC3 support.

	Mark

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

--
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: Jelte Jansen <[email-masked]>
Date: Thu, 04 Dec 2008 10:06:27 +0100

Mark Andrews wrote:
> 	future that will not support NSEC3.

>       Given that a number

me neither, but tell it to the chairs, they made me ;)

Apparently it has already been decided that there will be validators
that do not do nsec3, even if they cannot validate much of the internet...

But actually, there was a better reason to use algorithm number
signaling imho. I think Sam pointed me to that. That is that there are
no other nsec-type-signaling mechanisms, so until you actualy get NSEC
or NSEC3 records as a validator, you don't know what you are supposed to
get, opening you up for downgrade attacks if either NSEC or NSEC3 turns
out to contain an attackable problem.

Jelte

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Dec 2008 07:19:56 -0500

> 	to have seperate numbers.

Note that the text merely says that it's in keeping with the previous
approach.  All that means is that there's a precedent; that isn't a
claim of justfication.
 
> 	implementation not including NSEC3 support.

Why not?  I might want to build a non-validating (authority only)
system that can nevertheless serve NSEC and not NSEC3 records.  It
wouldn't be useful for TLDs, but it might be useful elsewhere.  See
also Jelte's point about downgrades.

During WGLC, there appeared to be many strong arguments in favour of
separating these pieces, and I heard no arguments in favour of keeping
them joined.  So that's what we've decided to do.  Speaking
personally, it seems to me that on grounds of feature isolation, it's
preferable anyway.  But speaking as document shepherd, my impression
of the rough consensus was that people wanted the NSEC/NSEC3
issue to be separate from the SHA2 issue.  I haven't so far seen
anything to suggest otherwise.

Best regards,
Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Dec 2008 23:28:24 +1100

In message <[email-masked]>, Jelte Jansen writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:
> > 

	It doesn't matter.  A answer will contain one or the other
	but not both for a given zone.  There is no downgrade attack.
	I can return NSEC or NSEC3 records with algorithm 7 today.

	Mark
 
> Jelte
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkk3nZMACgkQ4nZCKsdOncVzzQCfSrOOXZlXEpUUlLrkFcHkTzr/
> JT0AoLG9qmCrv5/bpRFtVGN267gjjPcb
> =5PjV
> -----END PGP SIGNATURE-----

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Dec 2008 23:49:57 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> wouldn't be useful for TLDs, but it might be useful elsewhere.

	And no one would know if you used algorithm 7 to do that
	and only served zones that contained NSEC records.  The
	only time the authoritative server needs to know how to
	return NSEC3 proofs is when the zone contains a NSEC3 and
	there is a appropriate NSEC3PARAM record there.

	The validator however needs to handle both both forms or
	it can't validate the returned responses.

> See also Jelte's point about downgrades.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Dec 2008 08:12:06 -0500

> 	it can't validate the returned responses.

But there'd still be a formal violation, because the server wouldn't
know what to do with NSEC3, at least in some reading of the
specification.  Remember, not every use of RFCs is for practical,
engineering-type purposes.  Sometimes, it has to do with checkboxes on
a conformance chart.  I don't see any reason to make that harder.
(Also, what would you do about the case where an admin who didn't read
the manual put an NSEC3 record in such a zone anyway?  Should the
server stop using SHA-2 in that case?  Just not run?  Catch on fire?
I can think of lots of different answers, but none of them benefit
from conflating two tangentially related issues, i.e. NSEC vs NSEC3 and
the algorithms involved in each case.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 05 Dec 2008 20:20:14 -0800

Jelte and all,

  Sorry for being silent so long.  Good point Jelte!  if nsec3 is
not used as a validator, the DNSSEC implemented in such a manner,
is nearly worthless for very useful purposes.

> -----END PGP SIGNATURE-----

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827