Subject: Re: [dnsext] Clarifying the mandatory algorithm rules

From: Matthijs Mekking <[email-masked]>
Date: Thu, 09 Dec 2010 10:59:09 +0100

Hi,

I would say you need to check the algorithms signaled in the DS RRset
(the already (in)famous section 2.2 from RFC 4035 implicitly says so).

Now whether the validator SHOULD or MUST check that the algorithms
signalled in the DS-set work: If the working group decides this should
be a SHOULD, validating resolvers will have a choice to fallback to "One
Signature Is Enough". In practice, this would probably be a
configuration knob algorithm-compromise-protection: "yes" or "no".

Although this is local policy, I also think it is bad policy for a
validator to allow algorithm compromises and badly signed zones. Thus, I
would go for a MUST here.

Best regards,

Matthijs

On 11/30/2010 11:43 AM, W.C.A. Wijngaards wrote:
> Hi workgroup,
> 
> The unbound implementation is the way it has been written, and I agree
> that changes have to be made to it.  Now, what is the right way?
> 
> On 11/22/2010 06:33 PM, Paul Vixie wrote:
>>> Date: Mon, 22 Nov 2010 07:58:53 -0500
>>> From: Edward Lewis <[email-masked]>
>>> ...
>>> DNSSEC is designed to protect against cache poisoning.  If there is a chain
>>> of trust to an RRSet, then the set validates, it has proven source
>>> authenticity and data integrity.
>>>
>>> Since time began (for DNS), there is always something wrong somewhere.  The
>>> goal is a robust system, not a tightly correct system.
> 
>> +1.
> 
> It would be good to have some text in bis-updates on this.  (I mean on
> the algorithm topic, the general leniency has been put forward by Alfred
> and others and I wholeheartedly agree with it :-) ).
> 
> It is clear that checking the set of algorithms present in the DNSKEY
> set is not a good idea, and checking the set of algorithms from the DS
> set is the right, more lenient way to go.  (so this is what Mark was
> proposing).  This is what validators use to determine if they can
> support the algorithms present in the zone today (and tomorrow).
> 
> However, there are choices that I see here, that change the security
> properties.
> 
> 
> * One Signature Is Enough
> 
> Check one signature, if it works, it's enough, and the added text is
> 'regardless of the algorithms signalled in the DS-set'.
> + it is lenient.
>   (it would have avoided the operational problems that incited this).
> + if a zone is badly signed, so it includes algorithms in the DS set for
> which proper signatures are not available, the validators that support
> both algorithms approve of this situation.
> - no algorithm-protection (explanation below).
> 
> 
> * Check the Algorithms
> 
> For the algorithms signalled in the DS set, check that there is a valid
> chain of trust for them.  Added text is, the validator SHOULD or MUST
> check (choice here) that the algorithms signalled in the DS-set work
> (but only for algorithms supported by the validator, of course).
> 
> + it is lenient because uses DS-set not DNSKEY-set.
>   (this allows the easier algo rollovers; it would have avoided the
> operational problems that incited this).
> - but not as lenient as 'one signature', this is the case of zones that
> are badly signed but have signalled the algorithm with their DS, so that
> a portion of validators are certain to fail for it.  Validators that
> support the other algo now also fail for it.
> + algorithm protection (explanation below).
>   + if SHOULD, local-policy decides what protection to apply.
> 
> 
> Algorithm compromise protection.
> This is a security property that the validation result can have or not.
>  Security algorithms have different properties, and by checking them you
> receive joined benefits.  Specifically, if one algorithm is 'broken'
> (but you do not yet know which one that will be), then you are protected
> against this because you check the other algorithm.
> 
> For zones that perform a single-DS rollover, this never applies, as the
> single DS makes validators check one algorithm anyway (since this
> minimizes communication with the parent, many zones can be envisioned to
> do this).  Other zones may have multiple DSes (or DLVs) and thus can
> have multiple crypto algorithms checked, at their option (and the
> validator local policy).
> 
> 
> I would like to know what the (seems rough) consensus is, so that I can
> go forward and implement this right.  It is then a good idea that Sam
> puts conclusions in the dnssec-bis-updates draft.
> 
> Best regards,
>    Wouter
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Dec 2010 08:44:20 -0500

>would go for a MUST here.

The reason it can't be a MUST is that a zone may be signed with 
algorithm 42.  If a resolver does not know algorithm 42, how can it 
determine whether the signature using algorithm 42 is valid or 
invalid?

Let's say a zone is signed by algorithms 5 and 7.  (A choice made 
specifically because the two algorithms have the same mathematical 
properties. ;))  What would you think if you received a set of data 
and signatures and discovered that the algorithm 5 signature 
validated the signature but the algorithm 7 signature did not.  What 
if the reason were cryptographic?  What if the reason was that the 
algorithm 7 signature had simply expired (with or without NTP 
running)?  What if the reason was that the algorithm 7 signature had 
not yet entered its effectivity period?

If you can establish a chain of trust to a data set, why withhold it 
from the application requesting it in case you find that there is 
also a signature that fails?

Assume a set of data has a legitimate signature in algorithm 5 that 
validates and you see an algorithm 7 signature that does not 
validate?  What if the cause of this was that an attacker wanted to 
perform a Denial of Service by applying an intentionally bad 
signature (which is trivial to do) to guarantee a failed chain of 
trust?  It's like allowing someone to say "don't trust the 
authorities, I'll insert some doubt so you won't use the information."

When you consider that it is far easier to insert harmful bad 
signatures than harmful bad data (because the latter requires a valid 
signature), you have to build the (or any security) protocol to be 
somewhat skeptical of it's own potentially-false positives.

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

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 09:04:05 -0500

There are two considerations here:

1) Ensure that a service is available as long as there is an
acceptably secure path
2) Enable reliance of weak algorithms to be discontinued before the
algorithm is broken

It is very easy to meet the first at the expense of the second. And
when the real life operational requirements are concerned, we have
problems with TLS in this respect as well.

The ability of a relying party to process an algorithm does not mean
that the relying party trusts it as secure.

In particular an RP may process an algorithm it does not accept as
secure. This is necessary since by default there is no authentication
on DNS at all

One concern here is that we do not want to force zones to discontinue
signing with an obsolete algorithm prematurely because that is going
to weaken the security of their site.

In the normal course of action, an RP that sees a site advertise 2
algorithms, only one of which is trusted, will only process the
trusted one and simply ignore the other, even if the trusted algorithm
fails.

But the same RP that visits a site that advertises only the untrusted
algorithm should probably process the chain and check for consistency
in any case since the alternative is to accept the data without any
checks at all.

If an RP sees a site advertise two algs and both are trusted, the RP
should probably choose one and accept the records if it succeeds.
Otherwise it should make a second attempt but the site cannot rely on
that.

On Thu, Dec 9, 2010 at 8:44 AM, Edward Lewis <[email-masked]> wrote:
> The reason it can't be a MUST is that a zone may be signed with algorithm
> 42.  If a resolver does not know algorithm 42, how can it determine whether
> the signature using algorithm 42 is valid or invalid?
>
> properties. ;))  What would you think if you received a set of data and
> signatures and discovered that the algorithm 5 signature validated the
> signature but the algorithm 7 signature did not.  What if the reason were
> cryptographic?  What if the reason was that the algorithm 7 signature had
> simply expired (with or without NTP running)?  What if the reason was that
> the algorithm 7 signature had not yet entered its effectivity period?
>
> If you can establish a chain of trust to a data set, why withhold it from
> the application requesting it in case you find that there is also a
> signature that fails?
>
> validates and you see an algorithm 7 signature that does not validate?  What
> if the cause of this was that an attacker wanted to perform a Denial of
> Service by applying an intentionally bad signature (which is trivial to do)
> to guarantee a failed chain of trust?  It's like allowing someone to say
> "don't trust the authorities, I'll insert some doubt so you won't use the
> information."
>
> When you consider that it is far easier to insert harmful bad signatures
> than harmful bad data (because the latter requires a valid signature), you
> have to build the (or any security) protocol to be somewhat skeptical of
> it's own potentially-false positives.
>
> --

-- 
Website: http://hallambaker.com/

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 09 Dec 2010 16:19:33 +0100

Hi Ed,

On 12/09/2010 02:44 PM, Edward Lewis wrote:
> determine whether the signature using algorithm 42 is valid or invalid?

Of course, the statement is still only valid for algorithms that the
resolver knows of. So it can still be a MUST.

> signature but the algorithm 7 signature did not.  What if the reason
> were cryptographic?  What if the reason was that the algorithm 7
> signature had simply expired (with or without NTP running)?  What if the
> reason was that the algorithm 7 signature had not yet entered its
> effectivity period?

When following the guidelines for "Check the Algorithms" with MUST, if
both algorithms are present in the DS RRset, and the algorithm 7
signature did not validate, the security status would be set to bogus.
The reason why the signature failed does not matter.

> from the application requesting it in case you find that there is also a
> signature that fails?

Because the zone operator specifically wants to be protected against
algorithm compromises and does that by listing more than one algorithm
in the DS RRset.

> validates and you see an algorithm 7 signature that does not validate? 
> What if the cause of this was that an attacker wanted to perform a
> Denial of Service by applying an intentionally bad signature (which is
> trivial to do) to guarantee a failed chain of trust?  It's like allowing
> someone to say "don't trust the authorities, I'll insert some doubt so
> you won't use the information."

A Denial of Service is always easy. Stripping the signature is just as
easy to perform a DoS attack.

Best regards,

Matthijs

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Dec 2010 10:47:07 -0500

>algorithm compromises and does that by listing more than one algorithm

DNSSEC is not designed to protect the zone operator, it is designed 
to protect the relying party.  Listing more than one algorithm is 
done to reach a wider audience, it does not enhance the security as 
far as the zone operator is concerned.

In the experimentation period before the first RFCs were produced 
(RFC 2052 being the first milestone) we played with the notion of key 
strengths.  (Keys, not algorithms because back then we only had the 
unencumbered DSA and the copyrighted RSA available.)  Trying to 
enhance the concept of DNSSEC by using the notion that one algorithm 
is better or one key is better than another failed time and time 
again.  When there's a weak link involved you can't overcome it.

What if your zone is signed with algorithm 42?  You might be more 
strongly signed than anyone else.  But what if you are delegated from 
a parent using RSA/MD5?  Your strengths are negated and if algorithm 
42 is not widely deployed you are even seen as unsigned to the masses.

So, so what if I say DNSSEC is not there to protect the zone 
operator.  Why does that mean that MUST is wrong?  The rationale is 
that no matter what you do, local policy is going to be followed. 
Local policy is going to prefer quick resolution of the query. 
Requiring DNSSEC to do extra or extraneous work is not constructive - 
by that I mean, once you've gotten a chain of trust why keep trying 
to find faults?  DNSSEC is not designed to be the last line of 
defense.

DNSSEC is never going to overcome weaknesses in the underlying 
cryptography.  Trying to do so is a futile quest and the relying 
party suffers.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 10 Dec 2010 10:08:41 +0100

On 12/09/2010 04:47 PM, Edward Lewis wrote:
> DNSSEC is not designed to protect the zone operator, it is designed to
> protect the relying party.  Listing more than one algorithm is done to
> reach a wider audience, it does not enhance the security as far as the
> zone operator is concerned.

Maybe it is not designed for this, but it sure is nice that it is
possible. I think both benefits apply: listing two algorithms (for
example, x and y) does not only give you algorithm compromise
protection, also a wider audience is reached. Now your zone is seen as
secure by validators that understand only x, or understand only y, or
understand both.

> In the experimentation period before the first RFCs were produced (RFC
> 2052 being the first milestone) we played with the notion of key
> unencumbered DSA and the copyrighted RSA available.)  Trying to enhance
> the concept of DNSSEC by using the notion that one algorithm is better
> or one key is better than another failed time and time again.  When
> there's a weak link involved you can't overcome it.

I am not making any assumptions about one algorithm being better than
the other, just because I use two of them.

> strongly signed than anyone else.  But what if you are delegated from a
> parent using RSA/MD5?  Your strengths are negated and if algorithm 42 is
> not widely deployed you are even seen as unsigned to the masses.

No: Your strengths are negated only if you accept only one signature.
But if the validator requires to check both signatures, your strength is
not negated.

If 42 is not widely deployed, meaning most validators do not understand
algorithm 42, then most validators will only use RSA/MD5 in this case
and construct the security status of responses based on that algorithm
only. So the masses still have some sense of security, they don't see
the zone as insecure.

> So, so what if I say DNSSEC is not there to protect the zone operator. 
> Why does that mean that MUST is wrong?  The rationale is that no matter
> what you do, local policy is going to be followed. Local policy is going
> to prefer quick resolution of the query. Requiring DNSSEC to do extra or
> extraneous work is not constructive - by that I mean, once you've gotten
> a chain of trust why keep trying to find faults?  DNSSEC is not designed
> to be the last line of defense.

The additional work is there for algorithm compromise protection. And as
I argued before, yes it is local policy to let the validator fallback to
"One Signature Is Enough". But it is kind of insane to me to have a
local policy that says 'allow badly signed zones'.

> cryptography.  Trying to do so is a futile quest and the relying party
> suffers.

And that's why I think it is nice that you can have a set of algorithms
to rely on. So in my opinion it is not futile.

But you do make a good point here: A name server using more algorithms
puts more work load on the validator. With that in mind, I am willing to
say that a SHOULD should be there.

Best regards,

Matthijs

---

From: Brian Dickson <[email-masked]>
Date: Fri, 10 Dec 2010 08:30:03 -0400

On Fri, Dec 10, 2010 at 5:08 AM, Matthijs Mekking <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I think there are two issues here.

One is, whether all signatures are of equal importance.

I'd say, SEP-related signatures (DS signatures, DNSKEY signatures) are much
more critical, and should receive maximum protection, performance
notwithstanding.

I'd also say,  the fewer labels there are, the more important, for the
same or similar reasoning.
The higher up the food chain, the bigger the target painted on the zone.

The second is, that accepting just *any* (valid) signature, means the
following consequence occurs:
If *I* choose which signature to check, the bad guy trying to spoof
the signature risks detection.
If the bad guy chooses (by ensuring only his spoofed signature will
validate, by stripping others
or replacing others with bad signatures), he can guarantee avoiding detection.

Even adding a randomization among known algorithms, and insisting that
a match must occur for that,
adds the probability of detection, without adding to the crypto burden
of the validator.

And something else that bothers me:

If $implementation does detect a validation failure, which in theory should not
be possible, what about signaling this to the zone owner/operator?

The zone itself might not be broken, but merely be under attack from
an off-axis attacker.
Or, the zone might be broken. There is no way for the validator to
know, and no way for
the owner/operator to currently discover this (automatically).

Should this be addressed? If so, how?

Brian

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Dec 2010 08:59:54 -0500

<no-hat>

Historical note and some observations:

The original intent of the DNSSEC design was as far as I can tell:
- One validating signature is sufficient
	
Once we had DSA rammed down our throat we started thinking about 
different algorithms, and the idea was:
- validator prioritizes the algorithms it supports, and sees signatures 
for.

Then during the RFC403x production the concept of downgrade attacks was 
brought up and the following rule was added
- all algorithms in DNSKEY must sign zone

At the time we failed to make the full connection between all the
moving parts in the DNS system
- The contents of the DS set
- The impact of zone distribution delays
- That for a while different caches/authorities may have different 
contents for the RRset and DNSKEY/DS records. (i.e. old DNSKEY set and 
newly signed RRset or vice versa).

For this reason the new text in DNSSEC best practices document says 
something like the following for introducing new algorithm:
	add RRSIG's,
	after a while add to DNSKEY,
	after a while add to DS
(and converse for retiring the algorithm)

During the long development phase of DNSSEC there was the concept of 
different policies by validators
  - paranoid
  - relaxed
The paranoid resolver will check everything,  the relaxed one will 
accept any single signature.

What Matthijs is effectively saying is he thinks paranoid is the way to 
go, while Ed argues that relaxed is the way to go (sorry for putting 
words in your mouths).
For what it is worth paranoid is what security people are more 
comfortable while relaxed is more what traditional DNS is about, and 
given how much some common DNS resolvers will bend backwards in 
accepting answers from broken implementations this is what large part of 
the world seems to expect.

My personal feeling is that zone publishers SHOULD assume all validators 
are paranoid and proceed accordingly. I to not think we can successfully 
prescribe either behavior or any variants in between.
Number of people have argued in the past that this should be a local 
configuration option.

The torture test is when you ask the following questions:
"Do you think paranoid is safer than relaxed?"

If the answer was yes:
"Are you willing accept not reaching <your best customer> because
their DNS setup is messed up?"

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Dec 2010 09:06:15 -0500

>more critical, and should receive maximum protection, performance

RFC 4034, section 2.1.1 says this:

# Bit 15 of the Flags field is the Secure Entry Point flag, described in
# [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a key
# intended for use as a secure entry point.  This flag is only zone signing
# or debugging software as to the intended use of this DNSKEY record;
# validators MUST NOT alter their behavior during the signature validation
# process in any way based on the setting of this bit.

All signatures are equal.

>same or similar reasoning.  The higher up the food chain, the bigger the
>target painted on the zone.

An attack to "steal" from example.co.tld. will be more effective if 
just that is "taken out" than if "tld." is taken out.  Why?  Who do 
you think is better defended?  How many will "fight back" if the 
attack goes to tld's infrastructure?

>Should this be addressed? If so, how?

I've already spent more time on this theoretical topic than I will 
ever spend on it in reality.

Can someone could actually demonstrate/deliver two RRSets for a 
name/class/type that validated against the same signature.  Even for 
RSA/MD5.  (Yes, I know MD5 is "broken" but every case I've heard of 
involves large, unstructured data.  Within the constraints of the 
DNS/DNSSEC protocol elements, can it be done?)

The restriction to the same owner/class/type is because the forgery 
would have to be tied to the question asked, RFC 2181 considerations. 
I'd be curious what is the minimum number of RR's needed in the 
forged set.  (Note - if the original set has one A record, the 
forgery can have more, many more.  If the minimum needed is absurdly 
high, then we can discount the odds that the forged set would 
accepted.)

(Wish we had put the RR's in set count in the RRSIG.)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Dec 2010 15:27:46 -0500

>say that a SHOULD should be there.

For the record, I'd put "could" and only that.

As in "a validator could check all of the signatures."  Doing more is 
deviating from the main purpose of DNS, that is quick, appropriate 
responses.

(Yes, I know "could" isn't an RFC 2119-defined term.)

In going through my family medical history I recently realized I was
born with congenital amnesia.  I couldn't even remember my name at birth.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Dec 2010 12:13:40 +1100

> - all algorithms in DNSKEY must sign zone

And the threat discussed was downgrade TO INSECURE by dropping
algorithms that were understood.  The solution to this was to
have the validator look at the list of algorithms in the DS RRset
to determine if it should treat the zone as insecure or not.

Instructions were then written to tell the SIGNER how to sign the
zone such that the VALIDATOR would always get a signture that could
validate if they were followed.  We were already aware that one had
to wait for the old zone content to flush before adding a DS.

There was no expectation that the validator would check this.

> Number of people have argued in the past that this should be a local 

Except there are degrees of paranoia.  Checking that you have
signatures for all algorithms in the DS RRset vs checking for all
algorithms in the DNSKEY RRset.

If a zone is supposed to be secure for a algorithm then it is
reasonable to check that it is secure for that algorithm.  Checking
this list of algorithms in the DNSKEY RRset does NOT do this.

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