Subject: Re: DNSSECbis Q-2: degradation attack

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Sep 2003 10:21:51 -0400 (EDT)

[Resending this, since tislabs.com seems to have trouble sending mail to 
namedroppers.  Sorry for the duplicate, if any.]

> > > the resolver may also impose certain minimums on things like key
> > > length to determine trust/reject?
> >
> > A client may certainly do this, but only if it would also reject
> > unsigned zones.  For example, you might say "I'll only accept DNS data
> > signed by 1024+ bit RSA/SHA-1 keys".  Dandy.  Then a zone choosing to
> > sign only with DSA is no less visible to that client than if it were
> > unsigned.  The danger comes when signing with 512 bit RSA/SHA-1 leaves
> > you inivisible where you weren't before.  We should prohibit clients
> > from doing that, to keep from providing disincentives to signing.
>
>       say what?  just how are you going to enforce this prohibition?
>       are you proposing that a client may not create a local policy
>       that states "if its not signed, it doesn't exist"?

What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1
keys'.  Dandy." didn't you understand?

Sure, a client may create that policy.  The policy I want to prohibit
is: "I won't accept any signed DNS data; I'll take unsigned data only;
if you sign your zone, you lose."  This, and its variants, violate the
safety property, and just like the (unintended?) policy of treating
all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC.

How do I plan to "enforce" it?  By publicly humiliating client authors
who do something different, much as we like to publicly humiliate
clients that don't do negative caching.  We can't keep clients from
shooting DNSSEC in the foot, but we can keep from writing a spec that
gives them a hunting license.

-- 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/>

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 2 Sep 2003 13:29:42 -0400

----- Original Message ----- 
From: "Samuel Weiler" <[email-masked]>
> all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC.

I don't think anyone can enforce client policy.  If a client refuses signed
answers (which is odd behavior, since the unsigned answer is the same minus
a few RRs), it is the client's perogative.  The server still is available to
everyone.  Pretty soon, the client will realize they are segregating
themselves from the rest of the net.

I don't think we can prohibit an overly strict policy either way (unsigned
only, or signed with a 4096 bit key only), but those that do so will have to
accept that the rest of the net might not have such strict standards.

I feel the issue of unverifiable data (unknown algorithm, lost key, etc.)
might need different considerations than known bad data (explicitly failed
to verify) with regards to caches.

Scott

---

From: Mike StJohns <[email-masked]>
Date: Tue, 02 Sep 2003 15:29:41 -0400

OK - Its possible we're all on different pages.  I've attached a PDF of a 
visio diagram which describes my understanding of what the output response 
should be for a query.

Brief explanation of the diagram terms:

If you ask a secure question you should get a secure response unless the 
zone is not secured.

Known Secure:  In certain circumstances, a query should return a secure 
response, and the resolver can reason from information it has to come to 
that conclusion.  Basically if there's a known trust anchor and the path 
information says the leaf answer should be secure an insecure answer should 
be considered bogus.

Valid direct chain means both that the origin of the signature chain is 
configured as trusted, and all the information up to but not including the 
leaf data SIG (of RRSIG) verifies.

Known Anchor - one of the reasons for not having a valid chain is that you 
don't recognize the anchor as trusted.  If you don't recognize the anchor, 
the DNSSEC info should be considered extraneous.  If you do recognize the 
anchor, then if the chain is invalid, the information should be considered 
bogus.

Verifies?: Means "does the final signature on the leaf information verify?"

Secure and Normal Response are self explanatory.  Bogus means that you were 
expecting a secure result and the information returned was unable to be 
validated using the information you had.

So putting this all together.

a) If a signature chain depends on an algorithm that the resolver doesn't 
implement, then the chain information is considered extraneous and the 
insecure data can be returned.  (This is the expansion of the "if I don't 
implement DNSSEC, then the DNSSEC info is extraneous" principle.)

b) If a signature chain contains multiple algorithms, all implemented by 
the resolver, then if at each node, there is at least one valid signature 
and at least one valid DS-KEY link exists at each delegation point, and the 
final signature on the leaf data is valid, then the chain is valid.

c) If, at any given node in the chain, considering only the algorithms the 
resolver knows, none of the signatures verify, then the data should be 
considered bogus.

Resolver policy gets to specify how the application treats data based on 
whether it thinks the responses are secure, insecure or bogus.

So continuing along that path:

In this document should go:

"A resolver MUST implement support for both RSA and DSA.  This requirement 
ensures the ability to transition to a secondary algorithm in the event of 
the primary algorithm becomes cryptographically tractable in the future 
(i.e. "broken").  For the foreseeable future, it is anticipated that RSA 
will be used as the primary algorithm for signing data in the DNS.  Any 
tools written to sign DNS data MUST default to RSA as the signature 
mechanism, but MUST also implement support for DSA signatures.  Those tools 
MAY implement support for other defined algorithms, but MUST default to not 
using those algorithms unless explicitly requested by the operator."

In a document on DNSSEC operational policy (a BCP) should contain:

"RSA MUST be used by all zone owners as the primary signature algorithm for 
DNSSEC zone signing.  Zone owners MAY also sign their zones with DSA.  The 
root zone, when signed, shall contain a complete set of both RSA and DSA 
signature records."

Sorry for the long winded description with diagrams... it was the only way 
I could actually get it straight in my mind.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Sep 2003 17:16:39 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Mike, thank you for the diagram. It looks correct to me.
It certainly answers the algorithm question for me.

A major question is what does the resolver do with all this information?

One thing I found weird about your diagram is that you have "Process Normal
Response" in the middle of the diagram, while "Treat Secure" is at the
bottom. 

It isn't obvious that the "Treat as Bogus" is also a terminal node. May
I suggest that you put them all at the bottom of the diagram?

Then, we are back to the problem of expressing three outcomes using only
1 bit when communicating with the application :-)

I had hoped to experiment with this question via a set of OPT replies in the
bind9 "lwres" interface. {Alas, I have no funding to pursue that at this
time}

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Miek Gieben <[email-masked]>
Date: Tue, 2 Sep 2003 23:33:15 +0200

[On 02 Sep, @23:16, Michael wrote in "Re: DNSSECbis Q-2: degradation ..."]
> 1 bit when communicating with the application :-)

is there any documentation about this API? Should I look at the lwred source
code from bind9? Or are we free to invent a new API?

grtz Miek

---

From: Mike StJohns <[email-masked]>
Date: Tue, 02 Sep 2003 17:38:02 -0400

>A major question is what does the resolver do with all this information?

That's another RFC.... "An application's view of DNSSEC"...:-)  Seriously 
though,  I'd be happy just to get the resolver to the secure, bogus, 
insecure state and then map that answer with the question against some sort 
of action/policy table.  E.g. someone who's trying to make an HTTPS 
connection may not care as much about the DNS mapping being secure if they 
can check the SSL certificate...but a mail forwarder may care a lot... *mumble*

>Response" in the middle of the diagram, while "Treat Secure" is at the

I did that to minimize crossed lines...  topological sort.  Among other 
things, I'm translating this into an ascii art diagram for inclusion into 
an RFC and fewer lines crossing is better.

>I suggest that you put them all at the bottom of the diagram?

All of the ovals are terminals....  Rectangles are processes and Diamonds 
are choices.

>1 bit when communicating with the application :-)

Yup..... much of it can be handled by setting the policy at the recursive 
resolver to translate the three into two according to some reasonable 
sorting algorithm... such algorithm is left as an exercise for the reader.

>bind9 "lwres" interface. {Alas, I have no funding to pursue that at this

Yeah...I need to look at what bind and other things do here...

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (GNU/Linux)
>Comment: Finger me for keys - custom hacks make this fully PGP2 compat
>
>iQCVAwUBP1UItIqHRg3pndX9AQHzMgQAlBXea9KI4jLK6KVk8qUWcOZfI9iIOwrQ
>vYusjg5I1Q+DWzp1lb6eHKcdZ3vwcmMP0r1ThMXie6aiAiKfJndkiHafaWXYDWgf
>fkwirMGxuzleqAdEkeAcv+HXOYMfQU789QOMTdrJ3wn6j22UBAKEQS0qOF7cl7No
>ZGg+Fz+QO+I=
>=ro8g
>-----END PGP SIGNATURE-----
>
>--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Sep 2003 18:49:24 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Mike" == Mike StJohns <[email-masked]> writes:

    >> A major question is what does the resolver do with all this information?

    Mike> That's another RFC.... "An application's view of DNSSEC"...:-)
    Mike> Seriously  
    Mike> though,  I'd be happy just to get the resolver to the secure, bogus, 
    Mike> insecure state and then map that answer with the question against

  Not enough.
  We have been down this route. 

  When it breaks, we get "SERVFAIL". There aren't very many people who can
diagnose the problem, even with resolver logs. Solution? Turn off DNSSEC.
  For this reason alone, we have to do better than this.

    Mike> sorting algorithm... such algorithm is left as an exercise for the
    Mike> reader. 

  I beg to differ. It might seem easy, but it isn't.
  It is critical that we do this right. Otherwise, DNSSEC gets turned off
because we can't distinguish two of the cases.  

    Mike> Yeah...I need to look at what bind and other things do here...

  Not lots yet.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Sep 2003 18:46:05 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:
    Miek> [On 02 Sep, @23:16, Michael wrote in "Re: DNSSECbis Q-2: degradation ..."]
    >> 1 bit when communicating with the application :-)

    Miek> is there any documentation about this API? Should I look at the
    Miek> lwred source code from bind9? Or are we free to invent a new API?

  lwres is built into bind9.
  It is presently just DNS over 127.0.0.1:953. I would actually prefer to
use Unix domain stream sockets - specifically so that I know that it is
local, and so that I can get signaled when the server dies, etc.

  I have just finished (yet another?.. not quite) async interface to
liblwres, which I'm about to post. It groks DNSSEC and follows CNAMEs,
which I need.

  Please note reply-to.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 03 Sep 2003 09:31:04 +0200

* Then, we are back to the problem of expressing three outcomes using only
 * 1 bit when communicating with the application :-)

Although important this issue is out of scope for this particular thread.

--Olaf
  DNSEXT Co-chair

---

From: Sam Weiler <[email-masked]>
Date: Wed, 3 Sep 2003 06:22:02 -0400 (EDT)

Thanks for the diagram.  Although I'd reorder some things, it sounds
like we're on the same page.

> a) If a signature chain depends on an algorithm that the resolver doesn't
...
> b) If a signature chain contains multiple algorithms, all implemented
...
> c) If, at any given node in the chain, considering only the algo...
...
> whether it thinks the responses are secure, insecure or bogus.

At a first pass, I concur with the above.

> root zone, when signed, shall contain a complete set of both RSA and DSA

I'm not sure how this follows from the a, b, c above.  Is there any
need to require RSA signing?  I think we can get away without it. The
last line "shall contain a complete set" is the bit I think is so
important, and it needs a MUST.

As for exact text, what do you think of the text I proposed on August
13th?

And I'm still indifferent as to whether or not we deprecate DSA.

-- Sam