Subject: Re: implied NSEC3 support in rsasha256 (was: [dnsext] Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05)

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Dec 2008 14:24:10 +1100

In message <Pine.LNX.4.64.0809301237230.27246@mint>, Sam Weiler writes:
> I have read this document.  Aside from the nits previously raised and 
> the below, it should go forward.
> 
> >>> I agree with the spirit, but since there is no immediately obvious
> >>> connection between NSEC3 and these two new algorithms, implementors
> >>> might deserve some explanation, otherwise this could come as a late
> >>> surprise.  If we're saving precious DNS security algorithm numbers,
> >>> we can say that ;-)
> >>
> >> From the document I read a zone that signs with RSA/SHA2 can use 
> >> either NSEC or NSEC3, thus and validator can not be sure until it 
> >> gets back an answer from the zone, which kind of negative 
> >> "expression" the zone uses.
> >>
> >> Are the members of the working group comfortable with this ?
> 
> No.  This creates an unneccessary link between two unrelated DNSSEC 
> parameters.  The danger is that if someone finds an attack that takes 
> advantage of NSEC3, zones may have to choose between being vulnerable 
> to that attack while using good hash algorithms and protecting 
> themselves from the NSEC3 attack while using poor hash algorithms. 
> Not a fun choice.

	There is no such risk.

        Zones operators have a choice of whether to generate NSEC
        or NSEC3 chains.  I can generate NSEC chains with algorithm
        5 or 7.  Both are equally secure.  The fact that one could
        generate a NSEC3 chain is irrelevent as one would also have
        to get the signatures on the NSEC3 chain accepted for there
        to be a threat and if you can get that to happen it doesn't
        matter if we are using NSEC or NSEC3 because the whole kit
        and kaboodle is gone.

        If the flaw is found then it is no worse than saying don't
        use 3 as the exponents with RSA.

        If you *only* had the choice of generating NSEC3 chains with
        the new algorithm number then your argument would make sense.
        One however would also have to go through the insecure state
        to transition from NSEC to NSEC3 and we specified the use of
        algorithm 7 to mean both NSEC and NSEC3 chains are possible.

        Currently we have

                TBA1 is NSEC.
                TBA2 is NSEC or NSEC3.

        What's the point of TBA1?

        B.T.W. Section 2.1, Paragraph 2 should start with "For the
        use of NSEC or NSEC3," to make that clearer.

        The only reason for having two numbers is if you believe
        there there is a reason to support validators which can do
        RSA/SHA-256 and not NSEC3.  I don't see a need to support
        that combination.

        Mark

> Is there any compelling reason to link them?
> 
> -- Sam
> 
> --
> 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/>
-- 
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: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Dec 2008 09:34:21 -0500

>         RSA/SHA-256 and not NSEC3.  I don't see a need to support

I determined during working group last call, however, that others
_did_ see a need to support that combination.  Moreover, I buy the
argument that we shouldn't link these two issues together.  If there
is a validator that can't do NSEC3 and they find they suddently want
to do SHA-2, why do we want to put an extra barrier in their way?

A

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

---

From: "Roy Arends" <[email-masked]>
Date: Tue, 9 Dec 2008 16:10:19 +0100

> to do SHA-2, why do we want to put an extra barrier in their way?

Such a validator _can_ implement SHA-2. Since such a validator explicitly 
does not implement NSEC3, it can now treat zones with these NSEC3 records 
as unsigned.
The method used in RFC5155 was to protect legacy validators against 
unknown extensions. Since RFC5155 is an integral part of DNSSEC, I see no 
reason to further forking the algorithm space. Imho, a validator does not 
have to understand NSEC3 to be able to validate, parse, or even signal its 
presence.

Regards,

Roy Arends
Sr. Researcher
Nominet UK

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Dec 2008 09:24:56 +1100

> to do SHA-2, why do we want to put an extra barrier in their way?

	Because it sets a BAD precident.  It means that you just
	cut down the effective algorithm space by half.  Yes it
	requires validator writers to support NSEC3 but I don't see
	that as a bad thing as it is a real world requirement to
	support NSEC3 if DNSSEC is ever going to fly.  We have
	several TLD operators stating that they intend to deploy
	NSEC3.

	Is there any DNSSEC validator vendor that is not planning
	to support NSEC3?  I'm aware of none.

	Mark

---

From: Matt Larson <[email-masked]>
Date: Tue, 9 Dec 2008 22:06:37 -0500

On Tue, 09 Dec 2008, Andrew Sullivan wrote:
> _did_ see a need to support that combination.

I do not believe the record supports that conclusion.

> Moreover, I buy the argument that we shouldn't link these two issues
> together.  If there is a validator that can't do NSEC3 and they find
> they suddently want to do SHA-2, why do we want to put an extra
> barrier in their way?

Roy already explained that a validator can support SHA-2 and not
NSEC3; their is no barrier.

I want to amplify Mark's comment about the impending need for
validators to support NSEC3.  The NSEC3 ship has sailed and is now
part of DNSSEC.  Let us not ignore operational reality while we
consider this particular piece of protocol engineering.  PIR has said
that .org will be signed with NSEC3.  While I cannot speak for Nominet
nor DENIC, all indications I've seen are that .co.uk and .de will be
signed with NSEC3 (as their representatives worked actively on the
protocol).  And, finally, I can most certainly assure you that when
.com and .net are signed, they will use NSEC3.  Those five zones
represent well over 50% of the total number of registered domain names
in the worldwide TLD market.  A DNSSEC validator without NSEC3 support
will shortly be either a useless antique or a laboratory curiosity.

As others have pointed out, the multiple algorithm hack was only
needed to protect past validators, not future validators.  There is
simply no reason to propagate this technique and it unnecessarily
reduces and complicates the algorithm space.

I regret that I did not notice paragraph 7 of Andrew's October 22 WGLC
message until this thread came back to life.  However, now that the
inaccuracies in that paragraph have been brought to light, and I have
gone back through the mailing list to examine the record, I strongly
oppose its conclusion.  The language regarding NSEC3 support from the
-05 version should be restored and we should not continue the
unnecessary practice of algorithm aliases.

Matt

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 10 Dec 2008 10:22:14 -0200

On Tue, Dec 09, 2008 at 10:06:37PM -0500, Matt Larson wrote:
...
> unnecessary practice of algorithm aliases.

+1

Fred

---

From: Peter Koch <[email-masked]>
Date: Wed, 10 Dec 2008 16:08:17 +0100

> I do not believe the record supports that conclusion.

I have my doubts here as well, but I feel a bit guilty at the same time.
In my post-WGLC review <[email-masked]>, archived
at <http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01828.html>
(missed the 4 weeks LC by another 4 days, but that's for the 'workflow' thread)
I wrote:

>> 5.2.  Support for NSEC3 denial of existence
>> 
>>    Implementations that have support for RSA/SHA-2 MUST also have
>>    support for NSEC3 denial of existence, as specified in RFC 5155
>>    [RFC5155].
>

This message was later quoted by Olafur in
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01852.html>
when he asked about the NSEC/NSEC3 unpredictability.

First, I'd like to restate that I agree with the spirit of declaring NSEC3
support "mandatory", or state of the art or "NSEC3 [is] an integral part
of DNSSEC".  As Matt correctly assumed, if/when DE is going to be signed,
NSEC3 is a MUST.  However, as ...

> NSEC3; their is no barrier.

... we saw just here, the language in -05 was probably too strong and an
explanation for implementers is really needed, at least the term "support"
must be clarified.

So, implementations of RSA/SHA-2 MUST be able to recognize and validate NSEC3
records, but they will treat those zones/responses as unsigned unless they
fully implement NSEC3.  Recognition and validation are necessary to avoid
downgrade attacks where the attacker substitutes NSEC RRs by random (NSEC3)
garbage.

> will shortly be either a useless antique or a laboratory curiosity.

Agreed, at least for general purpose validators.  But saying this en passant
in the RSA/SHA-2 spec isn't an optimum service to implementors.  And
assuming that the linear ordering of RFC numbers gives them a hint, isn't either.

> message until this thread came back to life.  However, now that the

Same here.

> unnecessary practice of algorithm aliases.

I agree that we should refrain from the continued algorithm aliasing, but
would like to propose a slightly different solution.  The draft should go back to
two instead of four algorith numbers.  The text regarding NSEC3 should
be clarified around 'support' and 'recognition'. RFC 5155 pretty well
documents the need for aliases, but it didn't make the step forward
explaining why this won't set precedent for future extensions.
Therefore, we should document, maybe in DNSSECbis-Updates, the decision and
the reasoning, so it's available for similar situations in the future.
Note that we might also want to strongly recommend NSEC3 as part of DNSSECbis
there, but these are separate issues.

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Dec 2008 10:16:05 -0500

Dear colleagues,

I recognise that there are several people who are unhappy with the
current text of draft-ietf-dnsext-dnssec-rsasha256-09.  

We have a few options:  

1.  Withdraw the request for publication (and, presumably, either come
    to some new agreement or abandon the effort).

2.  Hash this out during IETF last call.  

3.  Accept the document as it stands, with the compromise it contains;
    if we do this, we can also take the further action of preparing things
    so that next time, we don't have to alias the identifiers.

I think the second option imposes on the whole IETF a burden it
shouldn't have to face: we should have settled this in the WG.
(Plainly, I thought we had, or I wouldn't have sent the document
along.)  Therefore, from my point of view, the options are (1) or
(3).  If it appears to me that my earlier determination of consensus
was in error and no compromise is forthcoming, I'll default to option
(1).  

If you examine the discussion about this issue prior to the change,
you'll observe that the reasoning for it was simple: the single
identifier required that implementers not support one new feature
(SHA-2), but that they also accept a different feature (NSEC3).

I think it is entirely fair to observe that validators that don't
support NSEC3 are going to be more or less useless in future.  From a
process point of view, however, a naive implementer doesn't have a way
to learn that: RFC 5155 does not say that it updates any of the
DNSSECbis RFCs.  Perhaps it should, but it doesn't today.

Therefore, it seems to me that the objection against linking the
implementation of new algorithms with the implementation (or at least
recognition) of a new RRTYPE has considerable force in terms of the
protocol documents, even though the practical effect is blunted.  The
responses to this so far have suggested that NSEC-only implementers
don't need to implement NSEC3; this is true, but they have to
_recognize_ it.  That is is still a technical burden, and one that we
have nowhere else announced is necessary.

I think it would be a good idea to tell people that future algorithm
assignments will not alias the identifiers.  A good place to do that
would be in the dnssec-bis-updates document.  We have an urgent need
to complete that document anyway, because that's where the discussion
about different trust anchors is supposed to go.

If we insist on unifying the identifiers for these algorithms in
draft-ietf-dnsext-dnssec-rsasha256, rather than using aliases, then in
my opinion we need text for the document that explains the decision in
considerably greater depth, since even (some) readers knowledgable in
this area found the link perplexing when they reviewed the document.

I therefore ask those currently objecting to the algorithm aliasing
whether they can live with the current arrangement, with the proviso
that we will do something about this in dnssec-bis-updates.  (This is
option 3.)  I also ask those who object to the current text, and who
cannot support option 3, to state explicitly that they'd rather delay
deployment of SHA-2 than live with this compromise.

At the same time, I ask those who objected to the -05 text during WGLC
if they could live with putting the old -05 text back in, as long as
there was additional text explaining why the change.  (This is option
1.)  It would be very nice if you had proposed text to add, as well.
Note that the upshot of this will be a new draft with a substantive
change.  I therefore believe it will require another WGLC.

Best regards,

Andrew

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

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 10 Dec 2008 16:43:50 +0100

> there, but these are separate issues.

heh :)

in waiting for the chairs, i preemptively wrote this earlier today:

5.2.  Support for NSEC3 Denial of Existence

   Note that these algorithms have no aliases to signal NSEC3 denial of
   existence.  The aliases mechanism used in RFC5155 was to protect
   implementations predating that RFC from encountering records they
   could not know about.

   Implementations that support RSA/SHA-2 algorithms SHOULD also
   implement NSEC3 denial of existence [RFC5155].

   If an implementation chooses not to support NSEC3, it MUST at the
   very least recognize NSEC3 Resource Records and treat any zone that
   uses those as unsigned, after verifying the signatures on those
   records.

---

From: Matt Larson <[email-masked]>
Date: Wed, 10 Dec 2008 12:06:55 -0500

On Wed, 10 Dec 2008, Andrew Sullivan wrote:
> option 3.)

No.

> I also ask those who object to the current text, and who

http://en.wikipedia.org/wiki/False_dilemma

Your use of the phrase "delay deployment of SHA-2" is unnecesarily
dramatic.  What sort of delay are you talking about?  We already have
proposed text from Jelte.  Or put the -05 text back if there is
insufficient objection to that option.  Let's take until the end of
the week to bring this to a conclusion--from reponses to far it looks
to me like we are close to rough consensus--and then issue another
WGLC.  That's another two weeks, right?  I'll gladly wait another
month to avoid the clutter of more algorithm aliases.

Matt

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 10 Dec 2008 20:11:40 +0100

> shouldn't have to face: we should have settled this in the WG.

Personally I do not see that as a problem. The IETF has seen heavier  
burdens caused by cookies. Once the WG has agreed then its up for the  
AD to judge if this needs another IETF LC. If so, that is process that  
the IETF has been designed to handle.

My personal preference: Handle this in the WG, make sure we have  
hammered out all the issues and adapt a text. Then ask the AD for  
guidance on the next step.

FWIW, I think that we are dealing with a fairly academic issue given  
that major TLDs move towards NSEC3 and any serious resolver will need  
to support NSEC3 for DNSSEC and therefore I support Jelte's text.

--Olaf

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 10 Dec 2008 11:20:10 -0500 (EST)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

>        matter if we are using NSEC or NSEC3 because the whole kit

Mark successfully corrected me.  (Thank you, Mark.)

Given that, I have no objection to removing the aliases (with 
appropriate explanation, Andrew's option 1).  However, for the 
purposes of expediency, I suggest we take Andrew's option 3 and leave 
this document as it is.  It only uses two extra identifiers at the 
moment, which seems an acceptable loss.

-- Sam

---

From: Scott Rose <[email-masked]>
Date: Wed, 10 Dec 2008 16:44:25 -0500

> to support NSEC3 for DNSSEC and therefore I support Jelte's text.

I have read and support Jelte's text as well.  Failing that, I would
recommend going with Andrew's option 3.

Scott

> --Olaf

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Dec 2008 08:52:16 +1100

In message <[email-masked]>, Samuel Weile
> moment, which seems an acceptable loss.

	Which unfortunately sets a precident.  People won't go back
	and look at this discussion.  We need to send the right message,
	in rfc's, for people adding new algorithms.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Dec 2008 10:39:24 +1100

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

	Authoritatives servers is SHOULD.  This allow for NSEC only servers.
	Validators is a MUST.  A validator needs to be able to handle either
	NSEC or NSEC3 record or it need to treat the zone as insecure.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkk/47UACgkQ4nZCKsdOncUi1gCgyjNixFJLP9DAlbB5rvK6jA5V
> MXkAoM1S8XPMBIGAWgKFznUMRZZYwMxs
> =CV8x
> -----END PGP SIGNATURE-----
> 
> --

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Dec 2008 16:15:38 -0800

>>>>> On Wed, 10 Dec 2008 16:43:50 +0100, Jelte Jansen <[email-masked]> said:

JJ> in waiting for the chairs, i preemptively wrote this earlier today:

I was one of the LC reviewers that took issue with that section.  I
think that text looks good and avoids both the cost of allocating a new
type as well as mandating NSEC3.  Simply recognizing it and discarding
the results as unsigned seems like a good compromise so I'm all for the
new wording-ish.  I think marc's comments about what types of
applications (servers vs validating clients) should be taken into
consideration though.

I don't see the need to do a new LC since this is still resolving the
same issues from the last LC.  Part of the problem with the previous
text that was flagged by a few of us is that it wasn't explained.  Had
an explanation been in the text we probably would have still flagged it
as problematic but with a different complaint.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "Blacka, David" <[email-masked]>
Date: Wed, 10 Dec 2008 22:36:47 -0500

> DNSSECbis RFCs.  Perhaps it should, but it doesn't today.

Since, as far as I can recall, RFC 5155 didn't change anything in the  
previous RFCs, it didn't warrant a statement saying that it updated  
any.  Which is why it doesn't.

> have nowhere else announced is necessary.

Um, what?  I'm not at all certain how you got the impression that "the  
objection against linking the implementation ... has considerable  
force in terms of the protocol documents".

> about different trust anchors is supposed to go.

OK, I guess.

I'll admit that the intent that all future algorithms would imply  
understanding of NSEC3 (or, you know, the entire DNSSEC standard)  
wasn't captured in the NSEC3 RFC.  I suppose that is, to some degree,  
my fault.  I may have insisted that the document focus only on what  
NSEC3 was and how to implement it, rather than including instructions  
to the working group.

However, I remember fairly clearly that our intent when working on  
NSEC3 was to have future algorithms imply support for both NSEC and  
NSEC3.  And that we would handle this when we allocated the next  
algorithm.  Which is now.

> this area found the link perplexing when they reviewed the document.

Fair enough.  Jelte's proposed text looks pretty good to me.

> deployment of SHA-2 than live with this compromise.

For the record, I strongly favor option #1.

"Delay deployment"?  This may delay *publication*.  It is a bit of a  
stretch to say that we are delaying deployment.  You could deploy now,  
if you so wished.  If you need the imprimatur that getting the  
document through the glorious IETF process gives to deploy, I would  
suggest that you are in no rush.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Dec 2008 09:01:42 -0500

Dear colleagues,

Given the controversy, I've asked our AD not to proceed with IETF last
call. 

Since some of those who previously asked for the -05 text to change
appear to have withdrawn their objections to the single algorithm
identifier, it appears we can go with some variation of Jelte's
proposed text.  Thanks for your quick action, Jelte.

> 	NSEC or NSEC3 record or it need to treat the zone as insecure.

Mark, it would be helpful if you could provide a complete text for
consideration if you want Jelte's proposed text changed.  I'm not sure
I understand the above correctly, but if I do it isn't plain to me
that it entails anything different than what Jelte had.

Best regards,

A

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

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 12 Dec 2008 11:40:08 -0500 (EST)

> 	in rfc's, for people adding new algorithms.

Which Andrew has proposed doing in dnssec-bis-updates.  Is that not 
sufficient?

-- Sam