Subject: [dnsext] DNSSEC, robustness, and several DS records

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 May 2011 10:01:59 +0200

A recent incident lead me to re-study the question of "what a
validating resolver must/should do when there are several DS and some
are invalid in some way?" AFAIK (I would be glad to be corrected
here), the best common practice is to be lax ("DNSSEC is hard enough,
accept any DS"), following RFC 4035, section 2.4 and 5.3.1.

But it seems there is an "exception". RFC 4509, section 3, says that
DS hashed with SHA-1 must be ignored when there is a DS for the same
key hashed with SHA-2. This is to avoid downgrade attacks.

In the incident I was talking about, there were two DS for the same
KSK key, one hashed with SHA-1 and one with SHA-256 and the second one
was invalid, because of a bug (wrong Algorithm field). As a result,
both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while
there was another and perfectly valid DS record.

I question this rule: SHA-1 (as it is used for DNSSEC) is not broken
and the risk of downgrade attacks is ridiculous when you compare, both
to the other attacks on DNSSEC, and to the risk of creating an
error. Isn't it a case of excess security, which will turn people away
from DNSSEC (too much risk of breakage)?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 11 May 2011 09:45:38 -0400

> from DNSSEC (too much risk of breakage)?

Yes, it is such a case.

-- 
- Thierry Moreau

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 May 2011 09:57:32 -0400

>key hashed with SHA-2. This is to avoid downgrade attacks.
...
>from DNSSEC (too much risk of breakage)?

I gave this rule some thought too in the past couple of days, for the 
same reason.  I was never a fan of the rule but paid it no mind.  Now 
I think it is yet another example of a kink in the pipes that might 
eventually come back to haunt us.

The overriding policy is still "local policy rules."  It is fine for 
the document to say to implementers and deployers that if there is a 
choice between SHA-1 and SHA-2, prefer the latter because it is 
generally better.  "Generally" means that it is possible an operator 
could mess up the SHA-2 record (not the hash, the record).

Looking at other examples of this kind of preference, IPv6 over Ipv4, 
we see that sometimes promoting a new technology over an old can 
backfire in the transition phase.  More and more I think it is a 
mistake to bias a standard to one approach over another, instead, 
just inform the interested parties in the trade-offs.  If the 
underlying code is neutral, then we can adjust operations around 
changes in conventional wisdom.  Once we cement in a particular 
choice we are stuck.

Another set of principles I'd repeat - DNSSEC is a first line of 
defense, not a last line, meaning it's in the infrastructure and not 
the application.  DNSSEC has to be liberal because the impacts of a 
false positive are large and hidden under layers of code and GUIs. 
DNSSEC is to protect the cache and it is up to the cache operator to 
decide how to protect itself.  And the crypto-problem we are tackling 
is a subset of the general problem, a lot of the attacks (like 
downgrades) are just not all that realistic in the confines of DNS. 
DNS isn't immune, but the opportunities for a successful attack are 
limited.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 May 2011 07:13:30 -0700

>>>>> On Wed, 11 May 2011 10:01:59 +0200, Stephane Bortzmeyer <[email-masked]> said:

SB> But it seems there is an "exception". RFC 4509, section 3, says that
SB> DS hashed with SHA-1 must be ignored when there is a DS for the same
SB> key hashed with SHA-2. This is to avoid downgrade attacks.

Well, the reasons the WG decided to go that route at the time was there
is no way to ensure better security if you want better security and your
client is capable of it.  That last part of the sentence is the key (ha
ha) to understanding the real problem.

There is no signaling bit, from the publisher, to say that you want
people to only use the SHA256 record.  Thus, the RFC specifies this
policy as the default: "Validator implementations SHOULD ignore DS RRs
containing SHA-1 digests if DS RRs with SHA-256 digests are present in
the DS RRset."  Because there is no signaling bit, we end up in three
cases:

1) The zone publisher doesn't care which record is used.  Currently this isn't
   possible.

   * A SHA1 record exists
   * A SHA256 record exists

   Right now, the above SHOULD indicates you should only use the SHA256
   if you understand the SHA256.

2) The zone publisher *wants* everyone to upgrade, but cares about the clients
   that don't understand a SHA256 DS yet.

   * A SHA1 record exists
   * A SHA256 record exists

   This is the case the WG deemed more important than case 1.  Thus, the
   document STRONGLY ENCOURAGES people to only use the SHA256 record if
   they can understand it.

3) The zone publisher *requires* everyone to upgrade, but cares about
   the clients that don't understand a SHA256 DS yet.

   * A SHA256 record exists

   That's really the only bit that zone publishers can control: publish
   the SHA1 record or not?

If there was a way to publish the SHA1 record *and* a bit that said "use
anything you understand" this would be easier.  But there isn't a way to
do that.

So we need to pick, in the document, between which is more important: #1
or #2.  We picked #2.
-- 
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2011 07:27:50 -0700

> there was another and perfectly valid DS record.

Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact that the BIND and Unbound people treat it as a MUST seems like a bug.

> I question this rule: SHA-1 (as it is used for DNSSEC) is not broken

Correct.

> error.

Correct. 

> Isn't it a case of excess security, which will turn people away

No, because it adds no security, so it cannot be "excess security". It feels more like a case of a spec with a SHOULD that does not include guidance on when to consider an exception. If people here want to revise RFC 4509 to reflect security practices that balance risk from known attacks against cost to attackers, I would propose changing:

   Validator implementations SHOULD ignore DS RRs containing SHA-1
   digests if DS RRs with SHA-256 digests are present in the DS RRset.

to:

   If there is a known preimage attack on SHA-1 that reduces its
   effective strength to less than 128 bits,
   validator implementations SHOULD ignore DS RRs containing SHA-1
   digests if DS RRs with SHA-256 digests are present in the DS RRset.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 May 2011 10:28:33 -0400

Here's my take on it:

The attack for which the order matters (SHA-256 vs SHA-1) is a forged
DNSKEY, if I understand things correctly.
The DS records are signed as a single RRSET, so it is in theory impossible
to downgrade by blocking one of the DS records, unless you can forge an
RRSIG, in which case you're dead in the water anyway.

And, the "forged DNSKEY" attack can only succeed if the DS for SHA-1 is
used. By "forged", we mean a hash-colliding DNSKEY whose private keys we
know. Hash-colliding is hash-specific, so only one DS can be spoofed at a
time.

If DS records using SHA-256 and SHA-1 are both present and valid, using
SHA-256 makes the attack fail.

If only SHA-1 is present, the attack will succeed.

(Again, this is mostly hypothetical, as I understand it, i.e. that a forged
SHA-1 has not been demonstrated, as far as I know, which may not be very
far. ;-))

I would interpret the rule of (SHA-256 over SHA-1) as using the following
method:
(1) Take all your DS records, in whatever order they were returned or in
whatever order your local policy says to prefer them.
(2) If SHA-1 occurs before SHA-256 in the list, move SHA-1 or SHA-256 so
that their relative position in the list is swapped, i.e. that SHA-256
occurs before SHA-1.
(3) Go down the list, and attempt to validate the DNSKEY. Stop when you
succeed. If you fail all (fall through the end of the list), mark the zone
as (whatever is correct for this condition - bogus?)

While it is potentially susceptible to attack, it is still technically
secure.

Given that the data is likely to be present on all authoritative servers for
the zone, SERVFAIL is definitely not a good answer, IMHO.

And, if both SHA-256 and SHA-1 are present *and valid*, the downgrade is
prevented.

Brian

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 11 May 2011 16:28:34 +0200

Hi,

On 05/11/2011 03:57 PM, Edward Lewis wrote:
> The overriding policy is still "local policy rules."  It is fine for the

The policy that unbound uses for DS hash algorithm is this: it picks its
favorite (i.e. the strongest) algorithm from the set of available ones,
and ignores the others.  This works for algorithms other than SHA1 and
SHA2, and gives RFC 4509 behaviour for SHA1 and SHA2.

There would be algorithm protection if you checked all the available DS
hash algorithms.  But we did not implement this because RFC 4509 says
otherwise.

The favorite DS hash algorithm for unbound is the one with the highest
DS algorithm number.  This is an implementation trick.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 May 2011 12:39:23 -0400

At 7:13 -0700 5/11/11, Wes Hardaker wrote:

>1) The zone publisher doesn't care which record is used...
>2) The zone publisher *wants* everyone to upgrade...
>3) The zone publisher *requires* everyone to upgrade...

The zone publisher's wishes don't matter to DNSSEC.  DNSSEC is there 
to protect caches, first and foremost and that is what the protocol 
is designed to do.  The protocol does not convey the publishers 
wishes in any field.

"Trying to teach a pig to sing will just annoy the pig."  DNSSEC is the pig.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 11 May 2011 18:28:17 +0100

>   digests if DS RRs with SHA-256 digests are present in the DS RRset.

The problem is that we don't know if such attacks exist, and more practically
it's hard to update software. So it seems better to plan for the worst.

Besides, implementations may want to use dual algorithms, for example
elliptic curve plus RSA with a moderate size key, on the basis that it's
unlikely that anyone would be able to break both.

I really doubt having resolvers trying to fix up data errors is the way forward.

I think the real fix for mishaps uploading DS records is to have better
in-protocol support. The proposed CDS RRtype is aimed at this :

http://www.ietf.org/mail-archive/web/dnsext/current/msg10900.html

George

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2011 10:52:10 -0700

On May 11, 2011, at 10:28 AM, George Barwood wrote:

> it's hard to update software.

The first phrase is not true, and the second is not terribly relevant.

- There have been no known preimage attacks on SHA-1. When there is, the world will hear about it. And, before you say "but we might not hear about it", please understand that you can say exactly the same thing about RSA signatures themselves. Either you live with "the crypto experts will tell us when some component is unsafe", or you just freeze and don't do anything.

- If there is a preimage attack on SHA-1, or a much better attack on RSA, or...or...or..., then the software will have to be updated. It will will be hard to do so in some cases, but not in others.

> So it seems better to plan for the worst.

That logic leads to banning SHA-1 outright immediately. And yet the WG (correctly, IMNSHO) decided not to.

> unlikely that anyone would be able to break both.

To date, the tools used to weaken hashes are not the same as those used to weaken signature algorithms, so this sentence doesn't make sense in the current world.

> I really doubt having resolvers trying to fix up data errors is the way forward.

Fully agree.

--Paul Hoffman

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 May 2011 11:48:48 -0700

>>>>> On Wed, 11 May 2011 12:39:23 -0400, Edward Lewis <[email-masked]> said:

>> 3) The zone publisher *requires* everyone to upgrade...

EL> The zone publisher's wishes don't matter to DNSSEC.  DNSSEC is there
EL> to protect caches, first and foremost and that is what the protocol is
EL> designed to do.  The protocol does not convey the publishers wishes in
EL> any field.

That's another way of stating the problem, yes.  The protocol was
written to accommodate *one* view point of a publisher.  #2.  DNSSEC
is not a person, so it can't care.  Sure.  But it only supports #2 and #3.

EL> "Trying to teach a pig to sing will just annoy the pig."  DNSSEC is the pig.

Never said otherwise.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 May 2011 22:22:17 +0200

In your previous mail you wrote:

   Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact
   that the BIND and Unbound people treat it as a MUST seems like a
   bug.
   
=> I don't understand how the SHOULD can be interpreted in order to
avoid the "bug" (:-). Seriously you can disagree with RFC 4509
but not about the way it has to be implemented, i.e., your concern
is not about what it should be...

Regards

[email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 May 2011 17:04:05 -0400

> is not about what it should be...
The issue is the missing (but probably implied) text,  "and valid", in RFC
4509 (where SHA-256 DS record(s) are concerned).

In the case where the SHA-256 DS record has been pre-validated, well, it's
already a no-brainer.
In the case where the SHA-256 DS record has not yet been validated, ignoring
the SHA-1 before validating the SHA-256, is either suboptimal or erroneous.

The invalidity of an individual RR in a DS RRSET (where the DS RRSET's RRSIG
*MUST* already have been validated before considering the DS RRSET) can fall
into two categories:
- obvious operator error (wrong amount of data in the DS RDATA, or otherwise
malformed DS RDATA);
- "hash mismatch" against corresponding DNSKEY(s), which COULD be a
downgrade attack.

In the case of "suspected downgrade attack", the validity could be teased
out, if there were any other DS RR's in the RRSET.
The presence of any other DS RR algorithm which validates, would be enough
to "prove" the error is operator error.
The lack of any other DS RR algorithm (beyond SHA-1 and SHA-256), means a
downgrade attack cannot be completely ruled out.
(It's still paranoid to reject a valid SHA-1 when an invalid SHA-256 exists
and no other DS RR's are present.)

The SHOULD vs MUST boils down to:
- if SHA-256 is invalid, and SHA-1 is then used, this is a "SHOULD"
behavior.
- if SHA-256 is invalid, and a present SHA-1 is never checked, this is a
"MUST" behavior.

What Paul is (I believe) indicating is that doing the latter isn't quite in
keeping with the general spirit of the RFC, or in the "be liberal in what
you accept" philosophy.

Of course, if the SHA-1 is also invalid, then it is bogus.

Brian

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 May 2011 00:50:26 +0200

=> The RFC says:

so it doesn't say "valid" SHA-256 digests or something else.
I am sorry but there is one possible interpretation of the text,
of course we can agree the text is bad (:-). BTW I already signaled
there is no guideline for other (than SHA-1 and SHA-256) digest
algorithms so anyway a new document is needed...

Regards

PS: IMHO the idea of RFC 4509 is to replace SHA-1 by SHA-256
(and Paul shoud remark there is no well founded cryto reasons
to do that) so to provide both SHA-1 and SHA-256 is something
for the (now in the past) transitioning phase...
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Doug Barton <[email-masked]>
Date: Wed, 11 May 2011 17:47:59 -0700

> algorithms so anyway a new document is needed...

A) Insert obligatory rant about why "should" and "may" should never be 
used in standards documents.
B) I don't think it takes even the smallest leap of imagination to say 
that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1 
should be used and the SHA-256 should be ignored.

I think we could have a fine "angels-on-the-head-of-a-pin" debate about 
what "present" means in the RFC text, but I have a hard time believing 
that the intent of the text is that if you have something that works it 
should be ignored in favor of something that doesn't.

One could imagine a theoretical downgrade attack where the attacker 
somehow got access to the parent and was able to invalidate the SHA-256 
DS so that they could do their nefarious magic with the SHA-1 version, 
but if you could gain that kind of access to the parent wouldn't you 
have better ways to cause mischief?

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 11:28:32 +1000

> [email-masked]

Agreed.  You are either configured to follow the SHOULD or not and
the default is to fail.  Now not having a switch to turn it off
means you don't have a work around once you discover that DS is
wrong which requires contacting the administrators for the zone as
they are the only ones that can tell you whether it is wrong or you
are under attack.  You can make a educated guess without contacting
the zone administrators.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 11:58:06 +1000

> should be ignored in favor of something that doesn't.

Actually that was exactly the intent.  It was don't trust SHA-1 at all
if SHA-256 is present.
 
> have better ways to cause mischief?

The senario is that you have broken SHA-1 and can construct a working
DNSKEY which matches what the parent is publishing but have not
broken SHA-256.  If you trust SHA-1 then the attack works.  It you
don't trust SHA-1 the attack fails.  The rfc is assuming this will
happen before the reverse and is telling implementors to code for
it as if it was a current threat.

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 11 May 2011 19:45:34 -0600

Regarding the RFC4509 discussion,

I don't see why anybody would like to upload both a SHA-1 and SHA-2 DS
to their parent. With AM, CAT, CH, CL, COM, CZ, DK, EDU, FI, FR, GR, LI,
LU, MUSEUM, NET, NL, PM, RE, SE, TF, UK, WF and YT using only the SHA-2
algorithm for their DS in the root zone. Additionally, ARPA, BE, BIZ,
CO, JP, MY, XN--0ZWM56D, XN--11B5BS3A9AJ6G, XN--80AKHBYKNJ4F,
XN--9T4B11YI5A, XN--DEBA0AD, XN--G6W251D, XN--HGBK6AJ7F53BBA,
XN--HLCJ6AYA9ESC7A, XN--JXALPDLP, XN--KGBECHTV, XN--ZCKZAH all requires
a resolver to understand SHA-2 to be able to understand the DNSKEY in
their zone anyway.

I think it is fair to say that the DNSSEC functionality of a resolver
without support for SHA-2 is highly limited. As such I don't believe
that there are that many of them out there. (Am I wrong?)

Do like .COM and Just don't upload the SHA-1 and you will never have
this problem. We can perhaps have a different requirement wording in any
future RFC that is introducing a new DS algorithm. But for SHA-1 vs.
SHA-2 in reality this is not an issue.

I'm noticing that FR currently only has a SHA-2 in the root zone. I
guess they came to the same conclusion.

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of
>Mark Andrews
>Sent: Wednesday, May 11, 2011 8:29 PM
>To: Francis Dupont
>Cc: Paul Hoffman; [email-masked]
>Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
>
>
>In message <[email-masked]>, Francis
Dupont
>writes:

---

From: Doug Barton <[email-masked]>
Date: Wed, 11 May 2011 19:21:21 -0700

On 05/11/2011 18:58, Mark Andrews wrote:
> In message<[email-masked]>, Doug Barton writes:

Ok, so I guess we *do* need to have a debate about what "present" means. 
:)  To me, "it doesn't work" would indicate "!present," but I suppose 
reasonable minds could differ.

> it as if it was a current threat.

I get that, but I think we differ on the issue of "present." If there is 
a _working_ SHA-256 DS I agree with you completely.

--

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 12 May 2011 00:24:04 -0400

> a _working_ SHA-256 DS I agree with you completely.

If there is a working SHA-256 DS there is no issue.  The question is
what the resolver should do if it gets a DNSKEY that matches a SHA-1 DS
but doesn't match any SHA-256 DS.  It has no way to distinguish a
mistake in the SHA-256 DS data in the original zone from a downgrade
attack.

-- 
Matt

---

From: "Marc Lampo" <[email-masked]>
Date: Thu, 12 May 2011 08:10:18 +0200 (CEST)

Isn't the SHA-1 DS there to accommodate for validating caching name
servers that do not understand the SHA-256 "type" ?

Sorry to go somewhat off-topic, but still related to strengths of
algorithms :
Similar "problems" with the DNSKEY algorithms : RSASHA1, NSEC3RSASHA1,
RSASHA256 and ..512
A validating caching name server that does not understand a stronger
algorithm
treats the data as "unsigned"
+ great design of DNSSEC, this backward compatibility
- but pushing towards stronger algorithms, makes them being ignored by
"older" software

Last time I looked, Microsoft DNS topped at RSASHA1 (5);
the root uses algorithm 8
--> Microsoft DNS, even configured to validate, cannot even start to
validate.

No, I don't want to start a war of which vendor to use or not to use,
but by pushing towards better security,
the security level can be *reduced* !
(if the push is "too soon")

Kind regards,

Marc Lampo

-----Original Message-----
From: Stephan Lagerholm [mailto:[email-masked]] 
Sent: 12 May 2011 03:46 AM
To: Mark Andrews; Francis Dupont
Cc: Paul Hoffman; [email-masked]
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records

/S

Behalf Of
Dupont

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 May 2011 09:55:46 +0200

On Thu, May 12, 2011 at 12:24:04AM -0400,
 Matt McCutchen <[email-masked]> wrote 
 a message of 25 lines which said:

> The question is what the resolver should do if it gets a DNSKEY that
> matches a SHA-1 DS but doesn't match any SHA-256 DS.  It has no way
> to distinguish a mistake in the SHA-256 DS data in the original zone
> from a downgrade attack.

Can you explain how such an attack could be possible? Since the DS
record set is signed, modifying the SHA-256 record to make it invalid
(so the bad guy can attack SHA-1 with clever cryptanalysis) is not
possible (unless the bad guy can attack the provisioning channel and,
in this case, you're toasted, whatever the RFC says).

[Doug Barton already made more or less the same argument, if I
understand him correctly.]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 May 2011 09:58:10 +0200

On Wed, May 11, 2011 at 07:45:34PM -0600,
 Stephan Lagerholm <[email-masked]> wrote 
 a message of 84 lines which said:

> I think it is fair to say that the DNSSEC functionality of a
> resolver without support for SHA-2 is highly limited. [...] I'm
> noticing that FR currently only has a SHA-2 in the root zone. I

There are not only resolvers, there are also signing tools. We allow
SHA-1 DS in .FR because some users may be unable to produce SHA-2
DS. (Another solution would be to accept only DNSKEY and create the DS
ourselves but this is for another thread.)
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 12 May 2011 10:20:37 +0200

Hi Stephane,

> understand him correctly.]

The weakness in MD5 that I heard about (on slashdot I think) was that
you could construct data that matched a particular hash.  So, if the DS
contains some particular hash, then you produce a DNSKEY-dataset whose
hash matches the hash given.  And spoof the DNSKEY (not the DS).

However, even for MD5, the weakness that I once heard about needed a lot
of data (one megabyte? wasn't the example a postscript document?), which
would be hard to fit into a DNSKEY record in a way that you can still
use the DNSKEY to sign data.  Of course, you might want to get better
advice, such as from the authors of RFC 4509.  And they tell you to
ignore the SHA1 if a SHA2 is present.  with SHOULD (so, this is the best
thing to do, but there could be some exception, maybe for diagnostics or
so).

Best regards,
   Wouter

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 May 2011 15:35:06 +0100

W.C.A. Wijngaards <[email-masked]> wrote:
> you could construct data that matched a particular hash.

No, it's a collision attack. You can construct two things with the same
hash. You can't construct something to match a given hash.

This discussion seems silly to me, given that SHA1 is not likely to be
vulnerable for a long time, and we will be able to stop relying on it
before attacks become practical. We can rely on sensible behaviour by
hostmasters rather than building brittleness into the protocol.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2011 08:26:23 -0700

> you could construct data that matched a particular hash.  

You may have heard that on Slashdot; it is wrong. There has been no preimage attack reported on MD5 or SHA1 except on messages that are many terrabytes long, and even those take more than the 2^128 threshold that I proposed earlier.

--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Thu, 12 May 2011 12:05:32 -0700

On 05/12/2011 07:35, Tony Finch wrote:
> W.C.A. Wijngaards<[email-masked]>  wrote:
>>

Right, which, btw is an unstated assumption that I was making in my 
previous posts.

I fully agree that we need to move toward SHA-256. In fact in the past I 
advocated here that the dnssec-bis docs should eliminate SHA-1 
altogether, but I got shouted down out of respect for the "installed 
base" and deployment being "just around the corner." So if both work, 
sure, disregard SHA-1. Otherwise, go with what works.

Doug

--

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 May 2011 00:18:30 +0200

=> I don't follow your idea...

=> it is not a problem of imagination: either you implement what the
spec says or you implement something else. And IMHO the first option
is never a "bug".

   I think we could have a fine "angels-on-the-head-of-a-pin" debate about 
   what "present" means in the RFC text

=> present == is an element of the set

   but I have a hard time believing that the intent of the text is
   that if you have something that works it should be ignored in favor
   of something that doesn't.
   
=> but it is the intent: this is why I wrote there is no "valid"
in the spec (where my "valid" means your "works").

So I don't expect to see bind or unbound to change their behavior
unless/until a new rfc is published with another spec.

Regards

---

From: Doug Barton <[email-masked]>
Date: Thu, 12 May 2011 15:33:02 -0700

Francis, FYI your peculiar style of quoting previous text makes your 
messages very hard to read. More so when they are part of a 
traditionally quoted message like this one.

> =>  I don't follow your idea...

"Should" and "may" introduce ambiguity and allow different implementors 
to follow different paths, leading to multiple implementations that all 
arguably follow the spec, but don't interoperate.

> spec says or you implement something else. And IMHO the first option

And my point is that the language of the spec is unclear, which makes 
the proper implementation questionable.

> =>  present == is an element of the set

My point was that the debate centers around whether or not a DS record 
can be said to be "present," "an element of the set," or whatever other 
equivalent term you want to use; if it doesn't work. If what you are 
saying is that if it exists in any form, functional or not, then it is 
said to be "present," that's where we disagree.

> in the spec (where my "valid" means your "works").

And I think one could argue just as effectively that if what is meant is 
what you're interpreting then a sentence to the effect of "This is true 
even if the SHA-256 record doesn't work." should have been included. Or 
maybe not. I recognize that I could be wrong, but I don't agree that 
things are as cut and dry as you make them out to be.

> unless/until a new rfc is published with another spec.

And now we get to the heart of why "should" and "may" are bad for 
technical requirements documentation. If I were an implementor I could 
very easily look at the spec and say, "Francis is right, I SHOULD skip 
the SHA-1 record here whether SHA-256 works or not. But I don't like 
that interpretation of the spec, so I won't." Such an implementation 
would be just as compliant, by the letter of the spec, as one that did 
skip the SHA-1.

Doug

--

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 12 May 2011 21:48:15 -0400

On Thu, 2011-05-12 at 12:05 -0700, Doug Barton wrote:
> [...] So if both work, 

While you have defended your position amply, in your description you
continue to gloss over the issue.  The resolver does not know whether
the SHA-256 DS is "working" (it has no way to distinguish a
"non-working" SHA-256 DS from malicious replacement of the DNSKEY), so
what you literally stated above is unimplementable.  What I believe you
are really proposing, to honor the SHA-1 DS if the SHA-256 DS does not
match /for any reason/, is only as secure as the second preimage
resistance of SHA-1.

I just wanted to make sure this is clear in everyone's mind.

-- 
Matt

---

From: Doug Barton <[email-masked]>
Date: Thu, 12 May 2011 19:25:26 -0700

> I just wanted to make sure this is clear in everyone's mind.

Thanks for clarifying that. I was (obviously foolishly) thinking that 
there was a way to distinguish the 2 cases. In that case ignore 
everything I said, it should fail in Stephane's case.

Sorry for wasting everyone's time,

Doug

--

---

From: Francis Dupont <[email-masked]>
Date: Sat, 14 May 2011 14:11:21 +0200

=> if something can introduce an interoperability problem a MUST is
required. Here it is not the case so IMHO it is why a SHOULD is used.

=> it seems you are the only person which argues about the meaning
of "present"... i.e., I argue the languafe of the spec is clear.

   My point was that the debate centers around whether or not a DS record 
   can be said to be "present," "an element of the set," or whatever other 
   equivalent term you want to use; if it doesn't work.

=> if the "if it doesn't work" could matter it would be in the text,
there is no such thing so it doesn't matter.

   If what you are saying is that if it exists in any form, functional
   or not, then it is said to be "present," that's where we disagree.
   
=> it is what I said and I maintain.

   And now we get to the heart of why "should" and "may" are bad for 
   technical requirements documentation.

=> it seems there are 25 years of IETF just proving the opposite...
And ss an implementor I'd like to get more than MUSTs in technical
requirements (:-).

Regards

---

From: Brian Dickson <[email-masked]>
Date: Mon, 16 May 2011 13:00:56 -0400

> are under attack.  You can make a educated guess without contacting
There are subtleties in the logic for following RFC 4035, which RFC 4509
kind of glosses over with its "SHOULD" recommendation.
(IMHO, the "glossing over" is what creates the "bugs", when RFC 4509 is
looked at in isolation, without considering RFC 4035.)
When both 4035 and 4509 are taken together, those nuances become more
obvious. While there is room for different interpretations, some/most of
those lead to avoidable problems.
BTW - the motivation here is as follows: encode as much logic which is
unambiguous as possible, where that logic does not lead to weakness to
downgrade attack in the absence of significant operator error.
Encoding the "educated guess" into the resolver software minimizes the need
for resolver operator intervention to cases that can't be disambiguated.

Here's a fundamental arithmetic thing: In order for a SEP to be validated,
the DS record has to match all of the Key Tag, the Algorithm, AND the Hash
of the DNSKEY. (NB - both the Key Tag and the Hash depend on the Algorithm.)
So, two DS records with the same Key Tag, but different Algorithms, CANNOT
match the same DNSKEY. (Ditto for same Algorithm/different Key Tags.)

So, the important question is, should the "SHOULD" in RFC 4509 apply:
- Only to DS RRs that (appear to) refer to a single DNSKEY?
- Only to DS RRs which share an Algorithm?
- To all DS RRs without looking at Algorithm or Key Tag?

When there are two different algorithms, given that we (should) treat all
algorithms equally, I'd argue that this is a case where RFC 4509 should NOT
apply, IMHO.
This was the situation that Stephane experienced, FYI, although in his case
the values for Key Tag happened to still match. The separation by Algorithms
would have prevented the "bug" from resulting in "Bogus" / "Unknown" from
being the validation result.

I'd suggest that the most likely scenarios to be seen in production networks
will be DS sets that include both SHA-1 and SHA-256 for the same DNSKEY (and
thus algorithm), and possibly also additional DS record(s) with only SHA-256
on additional DNSKEY(s).

BTW - the reason for having one DS pair with SHA-1+SHA-256 (for one DNSKEY)
and another DS with SHA-256 ONLY (for a second DNSKEY), is that the
following properties apply:
- the SHA-256-ONLY DS *should* only get "touched" when there is activity on
the corresponding DNSKEY, and what doesn't get "touched" is unlikely to be
"broken". RRSIG validity is orthogonal to "breaking" the content of the
DNSKEY and its relationship to the parent's DS record.
- the DS with both SHA-1 and SHA-256 involves synchronized data, on two DS
records and a DNSKEY record. If the DNSKEY record is updated, and the DS
record for SHA-1 is updated but the DS record for SHA-256 is not, this would
be indistinguishable from a downgrade attack.

When you combine the two bullet points, and you get:
- fat fingers can break a single DNSKEY's validation modulo RFC 4509, but is
much less likely to invalidate both DNSKEYs if both types (SHA-256 only and
SHA-256+SHA-1) are present.

Since the attack vectors do not involve the DS sets directly, the presence
of DS records for a given algorithm that do not include SHA-256, suggests
operator error or deliberate choice, and alongside different algorithms with
SHA-256 (with or without SHA-1), those DS records of SHA-1 only should not
be ignored.
It is still more secure to have the method of implementing RFC 4509 be:
(0) validate the DS RRSET via its RRSIG(s).
(1) partition the DS RRSET into Algorithm subsets;
(2) for each Algorithm, if both SHA-256 and SHA-1 are present, suppress the
SHA-1 records
(3) do the rest of 4035 using the resulting DS RRSET (using whatever local
policy is, e.g. either require all Algorithms to validate, or require any
Algorithm to validate)

IMHO, of course.
Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2011 12:07:21 -0400

Some points responding to various issues in the thread.

1) No, it is not likely that we will have an issue with SHA-1 with respect
to DNSSEC. The reason for this is that DNSSEC is not used to provide
non-repudiation. Thus it is not necessary to be able to state today that we
are confident that SHA-1 will be acceptably secure in 20 years time.

I have asked Adi Shamir about likely progress on SHA1 and I think we are
good wrt DNSSEC for at least ten years.

2) Despite this, there is a cost to using non-standard or deprecated crypto.
Every single time someone wants to use a deprecated algorithm they have to
produce a justification for doing so. Those costs mount up and the point is
soon reached where the cost of constantly explaining why SHA-1 is safe is
greater than the switching cost.

I regret not proposing to upgrade DIGEST to SHA1 when we had the chance.
Even though it would not add any security to the scheme (any attack on the
digest construction is dominated by brute forcing the password space), it
would have saved time overall.

3) There are real benefits to making exactly one set of cryptographic
algorithms mandatory across all IETF protocols. At this point we don't have
much discussion over whether to make RSA or AES mandatory they are just the
default mandatory algorithms to be used across the board. I expect that the
SHA3 competition will result in a similar situation for Digest and MAC
functions.

That will still leave some niche requirements for RC4 and DSA and once all
the patents are expired there will be a likelihood of adding ECC. But as far
as mandatory to implement is concerned, I think we can limit the set to
RSA2048 + AES + SHA3 + SHA3-MAC.

4) Since SHA3 is being worked on right now, it would seem to me that the
appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip
straight from SHA1 to SHA3.

5) Since RSA1024 is in the process of being deprecated, DNSSEC may well turn
out to be one of the cases where there is an exception to requiring RSA2048.
DSA-SHA3 will be slower than RSA but the signatures created will be 512 bits
as opposed to 2048 and that is likely to make a difference for DNSSEC.

6) If we end up adding a mandatory algorithm we might well want to revisit
some of the other design considerations in DNSSEC. At the time Don made his
original proposals there were several optimizations that could have been
employed that were in patent. Now those patents are expired it may make
sense to re-open them.

One of the biggest hassles in DNSSEC is that the RRSIG records cover
individual record sets of the same type rather than all the records at a
domain. This is a fairly obvious candidate for using Merkle trees. So there
would be one public key signature for all the records in the zone and each
individual RRset would contain the intermediate tree nodes to enable it to
be verified.

The way I would do it would be to define a new Signature algorithm for
DSA+SHA3+Merkle Trees.

So my conclusion is that the group should take no action on SHA1 now but
that it should return to work on this topic after the SHA3 competition is
completed and it should consider a proposal that could start deployment long
before it became essential to make a switch.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 May 2011 18:38:41 +0100

> good wrt DNSSEC for at least ten years.

A useful point, thanks.

> straight from SHA1 to SHA3.

SHA2 is already widely deployed in DNSSEC, e.g. in the root zone and
many TLDs.

> domain.

Why is that a hassle? It seems like an advantage to me. In particular it
makes it possible to sign a dynamic zone where there is no such thing as
"all the records at a domain".

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2011 16:43:16 -0400

> "all the records at a domain".

It means that a client will frequently need to verify multiple RRSigs for
the same zone.

Using Merkle trees the public key operation can be done one per zone and
leveraged over all the records.

For example, let us say that example.com has A, AAAA, TXT and MX present.

The signature is calculated as follows

<sig>  = DSA ( H (  H ( H(A) + H (AAAA)) + H ( H(TXT) + H (MX) ) ))

The RRSIG records would be

A:  SIG + [H (AAAA)]  + [H ( H(TXT) + H (MX) )] + '0'
AAAA: SIG + [H (A)]  + [H ( H(TXT) + H (MX) )] + '1'
TXT: SIG + [H ( H(A) + H (AAAA))] + [H (MX] + '2'
MX:  SIG + [H ( H(A) + H (AAAA)) ] + [H (TXT)] + '3'

Note that each RRSIG is 512 + 256 + 256 + 16 = 1040  bits/130  bytes long
plus  whatever packaging is needed.

When validating this type of RRSIG the validator would first check to see if
it already has a signature verification result cached for the SIG value. So
even if there were 4 RR types in a zone it would only perform one public key
operation.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext