Subject: [dnsext] DS digest downgrade

From: "George Barwood" <[email-masked]>
Date: Mon, 21 Mar 2011 21:25:28 -0000

Via the dane group, I just realised that if DS records are provided for both SHA1 and SHA256, no extra security is obtained over using just SHA1.

That's because the SHA256 DS record could be for an unpublished DNSKEY in the child that happens to have the same Key Tag, so the verifier has to try the SHA1 digest if the SHA256 verification fails.

This seems unfortunate. You could have a rule that states that if SHA256 is used, it must be used "uniformly" ( or at least for all keys with the same algorithm and Key Tag ).

The alternative is to just not use SHA1 I suppose.

But this does seem like a design flaw, it's an obstacle for upgrading to better digest algorithms (SHA3?) if/when the current ones prove weak.

Was this ever discussed?

George

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Mar 2011 09:25:21 +1100

In message <AB3F9CFB9B6948139A2BE01269B399D5@local>, "George Barwood" writes:
> Via the dane group, I just realised that if DS records are provided for both 
> SHA1 and SHA256, no extra security is obtained over using just SHA1.
> 
> That's because the SHA256 DS record could be for an unpublished DNSKEY in the
> child that happens to have the same Key Tag, so the verifier has to try the 
> SHA1 digest if the SHA256 verification fails.
> 
> This seems unfortunate. You could have a rule that states that if SHA256 is u
> sed, it must be used "uniformly" ( or at least for all keys with the same alg
> orithm and Key Tag ).
> 
> But this does seem like a design flaw, it's an obstacle for upgrading to bett
> er digest algorithms (SHA3?) if/when the current ones prove weak.
> 
> Was this ever discussed?

I sugest that you go re-read RFC 4509.   SHA1 DS should be ignored if there
are SHA256 DS records.
 
> George
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "George Barwood" <[email-masked]>
Date: Mon, 21 Mar 2011 23:13:00 -0000

> I sugest that you go re-read RFC 4509.   SHA1 DS should be ignored if there

Ok, I see it now, section 3

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

That is actually what I implemented, the dane post got me confused
( http://www.ietf.org/mail-archive/web/keyassure/current/msg02093.html )

I think that RFC 4509 could have pointed out the subtle implications for the uniform
generation of DS records. There might be some risk that an administrator
fails to publish a required DS record ( possibly due to some parent constraint on the
total size of the DS RRset ).

i.e. the zone is using SHA1 DS records, admin generates new KSK, publishes SHA256 DS
for the new KSK but doesn't publish SHA256 DS for the old KSK, leading to validation failures.

George

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 00:38:40 +0100

In your previous mail you wrote:

   i.e. the zone is using SHA1 DS records, admin generates new KSK,
   publishes SHA256 DS for the new KSK but doesn't publish SHA256 DS
   for the old KSK, leading to validat ion failures.
   
=> this should never happen as the rule is in fact for the
replacement of SHA1 by SHA256 as the DS digest algorithm.
 But don't believe we are saved: there are other DS digest algos
(and even more to come) and the mixed algo case is dangerously
under-specified...

Regards

[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Mar 2011 08:11:53 -0400

>Was this ever discussed?

In the 90's, at the dawn of all this we considered downgrade situations.

DNSSEC is not there to protect the zone, it exists to protect the 
cache.  The cache is the element tha decides what to trust or not. 
Local policy and all that.

A zone only makes data available to the cache.  The more the merrier. 
Caches should be liberal in what they trust - but also firm in what 
they don't.  If SHA-1 is at risk, never use it, remove it from 
consideration.

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"

---

From: Derek Atkins <[email-masked]>
Date: Tue, 22 Mar 2011 09:00:36 -0400

> (and even more to come) and the mixed algo case is dangerously

It also doesn't help protect against an active man-in-the-middle who can
make sure that the validator never receives the SHA256 DS RR.
Unfortunately the validator can only validate what it receives; there's
often not a way for it to know what it should expect to receive.

> [email-masked]

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Mar 2011 01:03:06 +1100

> often not a way for it to know what it should expect to receive.

This attack is not possible.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 22 Mar 2011 14:10:22 -0000

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: "Francis Dupont" <[email-masked]>
Cc: "George Barwood" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 22, 2011 1:00 PM
Subject: Re: [dnsext] DS digest downgrade

> often not a way for it to know what it should expect to receive.

No, that's the whole point here.
The validators gets the (signed,validated) DS from the parent zone.
When it sees an algorithm in the DS RRset it expects the child zone to be signed with that algorithm
and if it isn't then the result is bogus.
Similarly ( as implied by RFC 4509 ) if it sees SHA256 in the DS RRset as a digest type, it expects to
be able to validate the DNSKEY RRset from the child using that digest type. 
If that's not possible then again the result is bogus.
So there is no problem, downgrade attacks are prevented, everything is good.
I was just confused momentarily by the Dane message from Matt.

George

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Mar 2011 07:13:54 -0700

>>>>> On Tue, 22 Mar 2011 09:00:36 -0400, Derek Atkins <[email-masked]> said:

DA> It also doesn't help protect against an active man-in-the-middle who can
DA> make sure that the validator never receives the SHA256 DS RR.
DA> Unfortunately the validator can only validate what it receives; there's
DA> often not a way for it to know what it should expect to receive.

The DS record will be signed by the RRSIG for the entire type, not just
a particular DS algorithm.  So if a man-in-the-middle removes the SHA256
DS record the validation of the entire DS set will fail.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Michael Graff <[email-masked]>
Date: Tue, 22 Mar 2011 15:14:02 +0100

> This attack is not possible.

To expand on this...

The DS records are signed by the parent, so a MITM attack against them
to modify them in flight would cause a signature failure.  Unless I'm
really confused about what Mark meant.

So, while it can cause validation failure (which makes the domain dark)
it can't be fooled into accepting something not intended by the publisher.

- --Michael

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Mar 2011 07:22:02 -0700

>>>>> On Mon, 21 Mar 2011 23:13:00 -0000, "George Barwood" <[email-masked]> said:

GB> I think that RFC 4509 could have pointed out the subtle implications
GB> for the uniform generation of DS records. There might be some risk
GB> that an administrator fails to publish a required DS record (
GB> possibly due to some parent constraint on the total size of the DS
GB> RRset ).

We deliberately stayed away from best-practices in the text because if
we went down that road it never would have been published :-/

You're right that this sort of discussion is needed somewhere, but as
others have pointed out there will/could be more and more algorthims for
more and more parts of the protocol and this situation (and transitions)
should be discussed in a single document, not in each individual one.
[though it would have been nice to refer to one]

What's worse, it takes careful coordination with your parent.

Consider the case where:

T+0: example.tld adds a new key
T+1: example.tld sends a SHA1 DS record to the parent
T+2: tld publishes the new DS
T+3: someone queries for the example.tld DS and gets a DS record set
     with the SHA1 DS for the new key.  And a TTL picked by ???
     [multiple options exist here].
T+4: example.tld sends a SHA256 DS record to the parent
T+5: tld publishes the new DS

If a parent only allows updating of a single DS record at a time, the
time between T+1 and T+5 could actually be on the order of seconds even,
but there is a time gap.  The whole process needs to document
parent/child relationships too, and the fact that the recommended
interface between the parent and child SHOULD accept multiple algorithms
simultaneously to prevent situations like the above.  So the advice to
the child gets even longer and more winded: if your parent only accepts
one record at a time, please publish the SHA256 first if you value
security.  Or SHA1 first if you value widest-interoperability (which I
actually doubt as I suspect everything? works with SHA256 now or won't
work at all in the first place, since SHA256 predates the NSEC3 records
which are now in such wide-spread use that you're chances of being
highly successful on the internet with SHA256 but no NSEC3 is unlikely).

As you can see...  it isn't a short bit of text that is needed.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Mar 2011 10:32:13 -0400

No hat.

>      [multiple options exist here].

I don't see why multiple options exist there.  The DS record is
authoritative data at the parent, and nowhere else.  Therefore, it is
the job of the parent and nobody else to set the TTL.

It might be that the parent has policies about how it sets the TTL
based on other factors, such as hints from the sponsor of the name
about the planned effective use period of the corresponding DNSKEY.
Certainly, if I ran the circus, that's how I'd do it.  But we need to
be quite careful in stating who has control of which data.

> If a parent only allows updating of a single DS record at a time,

It does seem to me that it would be a wise idea to provide operational
advice to DNS operators that accepting only one DS at a time is not a
good idea, precisely because the child side might have more than one
DNSKEY used as a KSK.  That would be operational advice, however, not
protocol.  If I were to put my hat back on, I'd note that such advice
would be the purview of another working group.

A

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 16:51:42 +0100

=> if the DS RRset is signed this is not possible.

=> this opens the door to DoS attacks but as far as I know
no more.

Regards

---

From: Joe Abley <[email-masked]>
Date: Tue, 22 Mar 2011 12:52:06 -0400

> => this opens the door to DoS attacks but as far as I know

I think that door was already open. If you can spoof a secure delegation response to a client, surely you can also spoof an NXDOMAIN or a SERVFAIL.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 23 Mar 2011 07:06:50 -0700

>>>>> On Tue, 22 Mar 2011 10:32:13 -0400, Andrew Sullivan <[email-masked]> said:

>> [multiple options exist here].

AS> I don't see why multiple options exist there.  The DS record is
AS> authoritative data at the parent, and nowhere else.  Therefore, it is
AS> the job of the parent and nobody else to set the TTL.

Because some upstreams let the user pick the TTL of the DS, wise or not.

Now, you're right it is the parent's responsibility...  But some
outsource that to the child.

AS> Certainly, if I ran the circus, that's how I'd do it.

I think you'd run a fine circus Andrew.

>> If a parent only allows updating of a single DS record at a time,

AS> It does seem to me that it would be a wise idea to provide operational
AS> advice

I agree, it would.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Mar 2011 10:23:04 -0400

> Because some upstreams let the user pick the TTL of the DS, wise or not.

I think we're saying the same thing.  I just want to be careful about
how we state it.

"The user" isn't picking the TTL: only the authority server (i.e. the
parent) can do that, in the strict sense.  What is of course true is
that the repository that generates the parent zone could accept
requests from its client for a TTL value on that data.  

What I'm trying to be precise about is the difference between
in-DNS-protocol data (and whose responsibility that is) versus data
that arrives as part of the provisioning actions that cause the DNS
data to be generated.  

A

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 23 Mar 2011 14:05:07 -0700

>>>>> On Wed, 23 Mar 2011 10:23:04 -0400, Andrew Sullivan <[email-masked]> said:

AS> I think we're saying the same thing.  I just want to be careful about
AS> how we state it.

I agree.

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 23 Mar 2011 22:48:05 -0400

[Note, I made the initial allegation of this issue in the dane/keyassure
group.]

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

I wasn't aware of this.  I did not think to check the specifications of
individual algorithms; I would have expected a specification that
modifies the validation requirements like this to update RFC 4035.  I
have submitted an erratum to this effect.

Ad-hoc SHOULD-level statements for validators are no way to achieve a
fundamental security property, and leaving the implications for the DNS
administrator as an exercise to the reader is no way to achieve
interoperability.  In my view, the issue cannot be considered resolved
until there is a single document that states the uniformity requirement
for DS records and a MUST-level requirement for validators in an
algorithm-general way.

-- 
Matt

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Mar 2011 14:51:28 +1100

> for DS records and a MUST-level requirement for validators in an

The time you get a failure is if there are differing DS algorithm
sets for the same DNSKEY algorithm and you are pre-publishing DS
and the pre-published DS has a SHA256 DS when the current DS for
that algorithm doesn't have a SHA256 DS but has a SHA1 DS.  This
will leave you with a SHA256 DS pointing to a non-existing DNSKEY.

If one is not pre-publishing DS records I don't see a failure case.
Treating the zone as insecure is not a failure.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 24 Mar 2011 00:18:44 -0400

> If one is not pre-publishing DS records I don't see a failure case.

Right.  Since an entire set of DNSKEYs is published, there are more
chances for things to work correctly, compared to DANE where the TLS
server presents just one of the designated certificates.

> Treating the zone as insecure is not a failure.

I disagree.  People are beginning to use DNSSEC to store opt-in
indications for application-level security mechanisms associated with
DNS names, such that treating the zone as insecure and allowing the
indication to be removed would be a security failure.  You might think
this is a bad idea, but the benefits of these mechanisms are compelling
and I think it would make more sense to beef up DNSSEC to support them
than to set up a parallel system.

What case are you thinking of in which the zone would show up as
insecure?

-- 
Matt

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Mar 2011 17:34:57 +1100

> What case are you thinking of in which the zone would show up as

Alg A has SHA1,  ALG B has SHA1 + SHA256.  Once you filter the SHA1
DS out you are left with just ALG B.