Subject: Re: [Design] Re: the KEY debate

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 15:05:33 -0500

on 8/7/2002 2:56 PM David Conrad wrote:
> On 8/7/02 12:07 PM, "Eric A. Hall" <[email-masked]> wrote:

>> Ugh. The more crap we put into DNS the less useful it will be for
>> lightweight lookups. We'll need another DNS if we pimp this one.
>
> Can we _PLEASE_ stop with this FUD?
>
> Explain exactly why adding a new RR type, one that does not change the
> underlying DNS algorithms, will have any significant impact on the DNS,
> much less make it "less useful".  On the contrary, it would make the
> DNS more useful, pretty much by definition.

Well-know fact that excess RRs bound to an owner will cause overflow of
UDP queries for qtype ALL. Adding "just one more" RR to a set means that
all first-pass queries for an overloaded owner name fail. Less useful.
Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful.

Cache overflow is already common in large ISPs. Less useful.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--
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: "Jason Coombs" <[email-masked]>
Date: Wed, 7 Aug 2002 10:55:02 -1000

> Can we _PLEASE_ stop with this FUD?

There IS a valid infosec perspective within this FUD.

Adapting DNS to distribute keys for applications other than DNS creates a
single point of security failure that impacts many applications instead of
just one, and that's bad.

When security evaporates suddenly due to bugs in DNSSEC deployments (bad
software) or in the unlikely event of a flaw in the protocol extensions to
DNS to enable DNSSEC, the damage is great instead of relatively small.
Consider the following real-world example of security evaporating suddenly
(RIGHT NOW!) with respect to SSL due to a bug in the way that Internet
Explorer processes (and trusts) certificate chains. And think about the
damage that would be done if something similar happens to DNSSEC with
APPKEYs (very, very bad, many applications left unsecured suddenly and
automatically) compared to the damage that would be done without APPKEYs
(revert to classic DNS security, effectively, but applications still have
their own independent mechanisms for establishing trustworthiness of the
work they do while bad DNSSEC software is patched and no DNSSEC lookups can
be trusted -- just as no SSL connections made using Internet Explorer RIGHT
NOW should be trusted: see below).

========================================================================
Internet Explorer SSL Vulnerability 08/05/02
Mike Benham <[email-masked]>
http://www.thoughtcrime.org

========================================================================
Abstract

Internet Explorer's implementation of SSL contains a vulnerability that
allows for an active, undetected, man in the middle attack.  No dialogs
are shown, no warnings are given.

========================================================================
Description

In the normal case, the administrator of a web site might wish to provide
secure communication via SSL.  To do so, the administrator generates a
certificate and has it signed by a Certificate Authority.  The generated
certificate should list the URL of the secure web site in the Common Name
field of the Distinguished Name section.

The CA verifies that the administrator legitimately owns the URL in the CN
field, signs the certificate, and gives it back.  Assuming the
administrator is trying to secure www.thoughtcrime.org, we now have the
following certificate structure:

[CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

When a web browser receives this, it should verify that the CN field
matches the domain it just connected to, and that it's signed using a
known CA certificate.  No man in the middle attack is possible because it
should not be possible to substitute a certificate with a valid CN and a
valid signature.

However, there is a slightly more complicated scenario.  Sometimes it is
convenient to delegate signing authority to more localized authorities.
In this case, the administrator of www.thoughtcrime.org would get a chain
of certificates from the localized authority:

[Issuer: VeriSign / Subject: VeriSign]
-> [Issuer: VeriSign / Subject: Intermediate CA]
   -> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org]

When a web browser receives this, it should verify that the CN field of
the leaf certificate matches the domain it just connected to, that it's
signed by the intermediate CA, and that the intermediate CA is signed by a
known CA certificate.  Finally, the web browser should also check that all
intermediate certificates have valid CA Basic Constraints.

You guessed it, Internet Explorer does not check the Basic Constraints.

==========================================================================
Exploit

So what does this mean?  This means that as far as IE is concerned, anyone
with a valid CA-signed certificate for ANY domain can generate a valid
CA-signed certificate for ANY OTHER domain.

As the unscrupulous administrator of www.thoughtcrime.org, I can generate
a valid certificate and request a signature from VeriSign:

[CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

Then I generate a certificate for any domain I want, and sign it using my
run-of-the-mill joe-blow CA-signed certificate:

[CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]
   -> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com]

Since IE doesn't check the Basic Constraints on the www.thoughtcrime.org
certificate, it accepts this certificate chain as valid for
www.amazon.com.

Anyone with any CA-signed certificate (and the corresponding private
key) can spoof anyone else.

========================================================================
Severity

I would consider this to be incredibly severe.  Any of the standard
connection hijacking techniques can be combined with this vulnerability
to produce a successful man in the middle attack.  Since all you need is
one constant CA-signed certificate (and the corresponding private key), an
attacker can use that to generate spoofed certificates for other domains
as connections are intercepted (on the fly).  Since no warnings are given
and no dialogs are shown, the attacker has effectively circumvented all
security that an SSL certificate provides.

There is some level of accountability, though, since a user who randomly
chooses to view the certificate of the web site she's visiting will see
the attacker's certificate in the chain.  However, by that point the
damage has already been done.  All "secure" data has already been
transmitted.

=========================================================================
Affected Browsers

Netscape 4.x and Mozilla are NOT vulnerable.

IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable.

When VeriSign issues certificates, usually they leave out the CA Basic
Constraint information all together.  Thawte tends to explicitly put in a
Basic Constraint CA = FALSE with the critical bit set to TRUE.

When the CA Basic Constraint on the middle certificate is explicitly set
to false and marked as critical, IE 6 does not follow the chain.  When
it's not mentioned at all, IE 6 follows the chain and is vulnerable.

This just means that an attacker needs to use a VeriSign-issued
certificate to exploit IE 6.

=========================================================================
Working Exploit

I've set up a URL to demonstrate this problem.  If you want to test
browsers not listed above or need proof of this vulnerability, contact me
and I'll give you the information.

=========================================================================
Vendor Notification Status

Last week I saw Microsoft downplay and obfuscate the severity of the
IE vulnerability that Adam Megacz reported.  After seeing that, I don't
feel like wasting time with the Microsoft PR department.

- Mike

--
http://www.thoughtcrime.org

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Conrad
Sent: Wednesday, August 07, 2002 9:57 AM
To: Eric A. Hall; Scott Rose
Cc: namedroppers
Subject: Re: [Design] Re: the KEY debate

On 8/7/02 12:07 PM, "Eric A. Hall" <[email-masked]> wrote:
>> I've been thinking the same thing - a BOF about using DNS to support
>> other applications and set up a general framework/process for getting
>> any type of network information in the DNS.
>

Explain exactly why adding a new RR type, one that does not change the
underlying DNS algorithms, will have any significant impact on the DNS, much
less make it "less useful".  On the contrary, it would make the DNS more
useful, pretty much by definition.

Rgds,
-drc

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 16:47:13 -0400

> UDP queries for qtype ALL. Adding "just one more" RR to a set means that

Luckily "qtype all" is generally only performed in debugging
situations and not by the majority of applications out there.
Can you give examples of applications that actually make queries
for qtype all?

> all first-pass queries for an overloaded owner name fail. Less useful.

HUH?  What do you mean "all first-pass queries?"  My SSH application
makes a query for "host.example. IN A".  What are YOU talking about?

> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful.

I'd be very surprised if you exceed a 64KB response!  You'd need to
add a LOT of 4k RRs to reach this size.  Also, that still presupposes
'qtype any' which is NOT what most application should be using
anyways.

> Cache overflow is already common in large ISPs. Less useful.

"cache overflow"?  What _ARE_ you talking about?

-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: Edward Lewis <[email-masked]>
Date: Wed, 7 Aug 2002 17:12:08 -0400

>Can you give examples of applications that actually make queries

dig -x does (or used to).

Perhaps also a debugging tool, but this is trivia I've carried for 
years and have been waiting to use it someday. ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 16:34:09 -0500

> "cache overflow"?  What _ARE_ you talking about?

More data than will fit in memory, resulting in data being dropped.
Overloaded caches (being unable to actually make use of cached data) are
less useful.

---

From: John Schnizlein <[email-masked]>
Date: Wed, 07 Aug 2002 17:43:23 -0400

>Can you give examples of applications that actually make queries

Would "qtype all" be the appropriate way for a DNS client to get
the RR-set so that it can check the validity of a signature?
Would "qtype all" be much more common when applications demand
assurance that the DNS reply is authentic?

Not taking sides, but the context of checking signatures should
be relevant.

John

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 17:51:07 -0400

> assurance that the DNS reply is authentic?

No.  A DNSSec-aware server is supposed to respond with the appropriate
SIG and NXT records on every query, so the client should not have to
query for qtype any.

> Not taking sides, but the context of checking signatures should

It is not.

-derek

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 18:29:14 -0400

David Blacka <[email-masked]> writes:

> >>>>> "Derek" == Derek Atkins <[email-masked]> writes:
> 
>  Derek> "Eric A. Hall" <[email-masked]> writes:
> 
>  Derek> I'd be very surprised if you exceed a 64KB response!  You'd
>  Derek> need to add a LOT of 4k RRs to reach this size.  Also, that
>  Derek> still presupposes 'qtype any' which is NOT what most
>  Derek> application should be using anyways.
> 
> So... 16 is a LOT?

For one application?  Yes.

> Exceeding the 64k limit for a single message looks like might be
> another credible argument against sub-typing application keying data.
> I could easily imagine having 64k of CERT or APPKEY-like records at a
> given name at some point.

Indeed.. You'll notice that I have abandoned the single-RR-type
approach for the rrtype-per-app approach.

-derek

> -- 
> David Blacka    <[email-masked]> 
> Sr. Engineer    Verisign Applied Research

---

From: David Blacka <[email-masked]>
Date: Wed, 07 Aug 2002 18:27:04 -0400

So... 16 is a LOT?

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:10:02 -0400

>assurance that the DNS reply is authentic?

Not really.  There's a different bit that a resolver uses to ask the 
server to return DNSSEC records.  In dig it is invoked with 
"+dnssec," in the protocol I forget whether it became a bit in the 
OPT record or not (DNSSEC OK bit)?

The problem with asking QTYPE=All to get the signatures is that this 
may be answered by a version of a name servers (some old BINDs) that 
may not keep the SIG records and just the data.  Repeatedly asking 
for All to that server will not get the SIGs returned until the TTL 
ticks down to 0 for all records at the domain name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:12:58 -0400

>SIG and NXT records on every query, so the client should not have to

That's changed.  Only if the client asks for it.  My old site was 
blocked (months ago) by another because our early DNSSEC-signed zones 
were returning answers too big - we tripped an IDS.  So to be kind to 
old code, DNSSEC records are only returned when the client requests 
them.

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 8 Aug 2002 10:04:30 -0400

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: "John Schnizlein" <[email-masked]>; "Derek Atkins" <[email-masked]>
Cc: "namedroppers" <[email-masked]>
Sent: Thursday, August 08, 2002 9:10 AM
Subject: Re: [Design] Re: the KEY debate

> OPT record or not (DNSSEC OK bit)?

Correct.  The +dnssec flag in dig adds an OPT record with the DNSSEC OK bit
set.  That's the only way to get DNSSEC records added to a response.  Unless
you ask for them specifically (or ANY, I would guess - haven't actually
tried).

The OK bit is like an flag to the server to say "DNSSEC capabile resolver
asking the query"