Subject: [keyassure] ESRV Record (Experimental)

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Sep 2010 17:11:44 -0400

A new version of I-D, draft-hallambaker-esrv-00.txt has been
successfully submitted by Phillip Hallam-Baker and posted to the IETF
repository.

http://www.ietf.org/id/draft-hallambaker-esrv-00.txt

This is joint work with Brian Smith of DNS.com.

I see two potential values to using DNSSEC. The first is that the
DNSSEC signatures may be used for key assurance. This represents a
convenience value and some additional benefits but is not a new
functionality. We have been using assured keys for 15 years already.

A much more interesting opportunity in my view is to put policy
statements into the DNS so that we can move from a default-insecure
status with the Web to default-secure. In particular if a customer
types in www.mybank.com into any Web browser, they are going to be
taken by default to the http version of the site. Only if they get to
the valid site does the SSL upgrade get requested. This represents a
major weakness in the current security of SSL.

The ESRV draft is a proposal I am planing to submit to the DNSEXT
working group as an independent RR proposal. Like the SRV draft before
it, this is a scheme that I believe is best addressed on an
experimental basis before adoption as a standard for connection
establishment. While the approach described is extensible, the
definition of the tags may not be optimal.

The idea of ESRV is that it supports meta-discovery of protocol
attributes. In particular security attributes and protocol discovery
mechanisms. At this point we have SRV and NAPTR and URI is on its way.
I actually like the URI approach but given the deployment of SRV how
do I know whether a given service is an SRV or a URI service?

Note that this draft is entirely independent of my key assurance
proposal which I am working on next. While both are built on the
assumption that security for the DNS is on its way, the two approaches
are quite independent except that of course that they make even better
sense if used in combination.

If you have ESRV and CERT records used together it is possible to get
to a point where every Web site uses SSL by default keyed of DNSSEC
assured certs and the role of CAs is to provide trusted third party
services as value added.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Sep 2010 17:47:11 -0400

On Tue, Sep 07, 2010 at 05:11:44PM -0400, Phillip Hallam-Baker wrote:
> working group as an independent RR proposal. 

To be clear (and as I'm pretty sure I've indicated before), there's no
submission here to "DNSEXT".  RRTYPE codes are assigned by expert
review.  The typecode assignment hews to pretty clear rules about
what's in and out.  This is all laid out in detail in
http://tools.ietf.org/html/rfc5395.

A

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

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 7 Sep 2010 16:52:36 -0700

On Tue, Sep 7, 2010 at 2:11 PM, Phillip Hallam-Baker <[email-masked]> wrote:
...
> http://www.ietf.org/id/draft-hallambaker-esrv-00.txt
...
> major weakness in the current security of SSL.

We are looking into this kind of policy assertion in DNS here at CMU,
possibly in conjunction with Strict Transport Security for HTTPS (
http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02 ), as
a way to defend against active network attacks on secure websites.

In the presence of an active network attacker who can modify and/or
drop packets in flight, we have a hard problem distinguishing a
website that wishes to assert "ssl=required" (in your terminology) via
DNS, but is under attack, from a website that makes no such
assertions.  If I understood your draft correctly, this would be the
RRset for a website at https://example.com/ with ssl=required:

example.com ESRV "disc=srv-e"
_http._tcp.example.com SRV 1 1 443 example.com
_http._tcp.example.com ESRV "ssl=required"
example.com A w.x.y.z

An active network attacker that wishes to downgrade an HTTPS session
to unencrypted HTTP can simply prevent the victim browser from
receiving any records but the A record.  The website thus appears to
be a legacy site that is ignorant of these DNS extensions, and is
supposed to be accessed over plain HTTP.

The attacker can do this without breaking DNSSEC authentication of the
A record itself, as far as I can tell.  Even end-to-end SIG(0) is not
enough to detect the attack, because at least two independent queries
are required to retrieve all the information in the above RRset -- one
for ANY example.com and one for ANY _http._tcp.example.com (again, as
far as I can tell) -- the attacker could just block the response for
the latter, at which point the browser is likely to fall back to HTTP
to the bare A record, rather than giving up entirely.  We do not
believe this is an unrealistic threat model; it's straightforward to
implement in, for instance, an 0wned wireless hub.

Do you have any thoughts on how this sort of attack could be defeated?

thanks,
zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Sep 2010 20:32:26 -0400

No, the NSEC/NSEC3 record contains a bit field that lists the records
that exist.

So an authoritative reply 'for record' not found should contain the
NSEC or NSEC3 record for that node with a bit field proving that the
record does not exist.

So the existence or non-existence of an ESRV record is established by DNSSEC.

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 7 Sep 2010 20:44:35 -0700

> NSEC or NSEC3 record for that node with a bit field proving that the

Yes, but an active network attacker can strip NSEC(3) records just as
easily as ESRV records.  I suppose it might need to strip DNSSEC
entirely to make it all look "natural" -- maybe if you query for
ESRV+A(+AAAA) and you get a signed A but neither an ESRV nor a NSEC(3)
for that ESRV, that's enough to infer shenanigans, especially if we
can start treating the lack of a signature for the A(AAA) as a problem
soon.  Thing is, though, I don't think a stub resolver can reliably
tell if that's happened.

Now, I'm a security researcher first and a browser implementor second.
 With either hat on, I'm prepared to consider embedding a full
recursive, DNSSEC-aware resolver in the browser, if that's what it
takes to make this work reliably (similarly for any other application
with this level of security needs and backward compatibility
constraints).  However, *the specifications coming out of this WG need
to address these issues,* from both the security-considerations and
implementation-advice perspectives.

[ With either hat on, also, I have no interest in CA vs. DNS turf
wars.  Maybe five years from now, if fingerprint-in-DNS or key-in-DNS
becomes really popular, we could have a conversation about whether DV
certs are still useful, but it's a total distraction today. ]

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 00:29:11 -0400

If the NSEC/NSEC3 records are not present then the zone does not verify.

The resolver signals support for NSEC or NSEC3 by means of the
specification of the algorithm in the DNSKEY record. But one or the
other is required to be present.

There is certainly enough there to call shenanigans in the case of an
active attack. The difficulty arises in trying to distinguish
intelligently between shenanigans and incompetence on the part of the
zone admin.

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 7 Sep 2010 23:00:49 -0700

> other is required to be present.

Suppose this is the complete example.com zone:

example.com. SOA ( ... )
example.com. NS ns.example.com.
ns.example.com. A 10.0.0.1
www.example.com. A 10.0.0.2

and it's been signed, then a query for ESRV example.com. should return
an empty answer section, with an NSEC record for example.com and its
RRSIG in the authority section (as well as the SOA and its signature).
 But if the domain has not been signed, then the same query returns an
empty answer, and only the SOA record in the authority section.  This
is what I meant when I said "[an active attacker] might need to strip
DNSSEC entirely to make it look natural".  They may not be able to
fake the verified absence of a record in a signed zone, but they can
make it look like the zone isn't signed at all.

Or an active attacker can blackhole the entire response packet for the
ESRV query, but let the response packet for an A query for
www.example.com. through.  In some ways that looks *more* natural -
that might not be an attack at all, that might be a badly designed
router (or, more likely, recursive resolver) that throws away DNS
packets containing any record type it doesn't understand.

Okay, what do we do about it?  Well, here's an attack-detection
strategy that might work for HTTP/s in the context of your proposal--
this is entirely me thinking out loud, so please do poke holes in it
--

1)  Given the URL http://example.com/..., browsers are to look up all
these records (AIUI these would have to be four separate query
packets, therefore four separate responses that could be individually
downgraded to insecure DNS even in the presence of SIG(0)).

    + A example.com.
    + AAAA example.com.  (if IPv6 is available)
    + ESRV example.com.
    + SRV _http._tcp.example.com.  (maybe only if the ESRV says so?)

2) If *any* of these queries returns a signed response, then *all* of
them must return a signed positive or negative response.  If this
condition is violated, browsers are to refuse to display the website.
(I envision this being like the phishing-site screen rather than the
bad-cert screen -- no way to click through.)

3) ESRV must only be used in signed zones; if an ESRV record is
received with no signature, browsers are to refuse to display the
website, period.

Under this policy, the active attacker cannot downgrade ssl=required
without also downgrading out of DNSSEC altogether, I think.  And with
the root zone signed, I think we might be able to persuade all browser
vendors to put the world on notice that DNSSEC will become mandatory
for HTTPS at some date certain.

> intelligently between shenanigans and incompetence on the part of the

Under my suggested policy, the active attacker can DoS the website,
and an incompetent zone admin can self-DoS, but both are prompt, overt
failures which will get corrected quickly, one hopes.

zw

---

From: Chris Wright <[email-masked]>
Date: Wed, 8 Sep 2010 17:06:22 +1000

> But if the domain has not been signed, then the same query
> returns an empty answer, and only the SOA record in the authority section.
> This is what I meant when I said "[an active attacker] might need to strip
> DNSSEC entirely to make it look natural".  They may not be able to fake
> the verified absence of a record in a signed zone, but they can make it
> look like the zone isn't signed at all.

I think you are missing one important piece to the puzzle. A validating recursive server, that has been asked to do DNSSEC will not accept any unsigned responses for domains that are signed. The fact that a domain is signed, is indicated by a DS record being present in the parent or in most DNS software by the configuration of a trust anchor at that point.

Thus if the A record is signed, and proper DS records are in place (or a trust anchor) the recursive server will be expecting and will only accept signed responses thus the existence (or  non-existence) or ESRV records will also be securely proven, nothing an attacker can do about it.

The point about mandating the use of DNSSEC when using ESRV records makes some sense though.

My question is, how much of this is in scope with the potential working group and how much not?

Thanks

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zack Weinberg
Sent: Wednesday, 8 September 2010 4:01 PM
To: Phillip Hallam-Baker
Cc: [email-masked]
Subject: Re: [keyassure] ESRV Record (Experimental)

example.com. SOA ( ... )

and it's been signed, then a query for ESRV example.com. should return an empty answer section, with an NSEC record for example.com and its RRSIG in the authority section (as well as the SOA and its signature).
 But if the domain has not been signed, then the same query returns an empty answer, and only the SOA record in the authority section.  This is what I meant when I said "[an active attacker] might need to strip DNSSEC entirely to make it look natural".  They may not be able to fake the verified absence of a record in a signed zone, but they can make it look like the zone isn't signed at all.

Or an active attacker can blackhole the entire response packet for the ESRV query, but let the response packet for an A query for www.example.com. through.  In some ways that looks *more* natural - that might not be an attack at all, that might be a badly designed router (or, more likely, recursive resolver) that throws away DNS packets containing any record type it doesn't understand.

Okay, what do we do about it?  Well, here's an attack-detection strategy that might work for HTTP/s in the context of your proposal-- this is entirely me thinking out loud, so please do poke holes in it
--

1)  Given the URL http://example.com/..., browsers are to look up all these records (AIUI these would have to be four separate query packets, therefore four separate responses that could be individually downgraded to insecure DNS even in the presence of SIG(0)).

    + A example.com.

2) If *any* of these queries returns a signed response, then *all* of them must return a signed positive or negative response.  If this condition is violated, browsers are to refuse to display the website.
(I envision this being like the phishing-site screen rather than the bad-cert screen -- no way to click through.)

3) ESRV must only be used in signed zones; if an ESRV record is received with no signature, browsers are to refuse to display the website, period.

Under this policy, the active attacker cannot downgrade ssl=required without also downgrading out of DNSSEC altogether, I think.  And with the root zone signed, I think we might be able to persuade all browser vendors to put the world on notice that DNSSEC will become mandatory for HTTPS at some date certain.

> intelligently between shenanigans and incompetence on the part of the 

Under my suggested policy, the active attacker can DoS the website, and an incompetent zone admin can self-DoS, but both are prompt, overt failures which will get corrected quickly, one hopes.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 10:26:12 -0400

I am posting the draft here for interest and comment rather than
proposing it as a WG item at this stage. It is really not at all clear
to me that we even need a WG. We only have one point of dispute as far
as the actual bits on the wire goes. So the scope of the WG would be
limited to working out what those bits on the wire actually deliver.

As for the technical issue, there are really two sets of answers here.

The first is that if you look at DNSSEC as designed then it is
designed to prevent a downgrade attack and does so perfectly well.

The second is how you can use DNSSEC in practice in a world where
admins are not necessarily competent and the desired behavior for
applications has been totally ignored by the DNSSEC design team as
'someone else's problem'.

Now there is a practical answer to the second problem but it involves
a totally different model of how DNSSEC is employed.

Consider how spam filtering evolved. Early on everyone was running
spam assassin on their mail server. But after a while people started
to realize that the key to effective mail filtering was volume.

If you are filtering a few thousand emails a day on a single server
you can't do much more than naive content analysis because you just
don't have enough volume to apply more sophisticated analysis. If you
are filtering a few million messages an hour you will see each spam
multiple times and you have far more data points to work with.

A similar situation holds true with use of DNSSEC data. If you are
looking at a single retrieval it is really difficult to make sense of
the DNSSEC data because you are looking at one snapshot in time. If
you have access to state information from previous interactions you
can do much more.

It is pretty difficult to distinguish incompetence from an attack at
the endpoint but quite easy to do so at a moderately busy DNS
resolver.

That is why it is necessary to distinguish 'DNSSEC' and 'Secure DNS'.
Since the model that I anticipate prevailing at the end point is to
establish a secure tunnel to a state-full resolver that is performing
some degree of intelligent analysis on the raw DNS, DNSSEC and other
data.

Remember here that the objective is to protect the USER and not the DNS.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 11:10:47 -0400

On Tue, Sep 07, 2010 at 08:44:35PM -0700, Zack Weinberg wrote:
> entirely to make it all look "natural" 

No, that's not how DNSSEC works.  This isn't the right list to explain
it, but you can't tamper with a DNSSEC-signed zone's responses and
still get them validated.  They'll fail to validate and be marked bogus.

> constraints).  

The only way to get reliable, trustworthy data out of the DNS is to
use DNSSEC.  It is a mechanism that allows you to prove that the
answer you got is the one that's in the zone (where "in the zone"
includes records that have been cached and are no longer on the
authoritative servers but used to be). 

> However, *the specifications coming out of this WG need

Clearly, if you're going to trust the answer you get out of the DNS,
you need to be using DNSSEC.  That's the same thing we've been saying
for some time, now.

A

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