Subject: Re: [dane] Call for consensus on level of DNSSEC support

From: Tony Finch <[email-masked]>
Date: Thu, 1 Dec 2011 11:41:44 +0000

Martin Rex <[email-masked]> wrote:
>
> If you have a roaming device with a secure resolver (i.e. the root
> zone key locally configured) and you are either a static host and
> behind a middle box that impairs DNS lookups but lets DS records pass,
> or a mobile host that is caching DNS records (including DS records
> for a zone) and you roam to an area where a middlebox prevents you
> from further receiving some of the zones records for whatever reason
> so that you can not perform a signature verification,
> then both 4033 and 4035 say that all lookups for that zone
> are to be flagged as "bogus".
>
> I believe DANE should avoid creating new interop problems.

These are DNSSEC problems not DANE problems, so should be dealt with in
the dnsext and dnsop working groups.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: Westerly veering northerly 4 or 5, occasionally 6,
increasing 7 in west Sole. Rough or very rough, occasionally high in west
Sole. Squally showers. Mainly good.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Dec 2011 08:09:11 -0500

> I believe DANE should avoid creating new interop problems.

Of course they're flagged as bogus.  They _are_ bogus.  Something is
standing in the way and removing DNS data.  That's a MITM, and it's
exactly what DNSSEC is supposed to detect.  What's the problem?

This is like claiming that there's some special interop problem
created by IMAP because a lot of hotel networks only permit
connections on port 80.  It's the network that's broken in that case,
and DANE isn't creating a new interop problem.

If, however, you don't like this feature of DANE, don't use it.
Surely nobody is forcing you to do so.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2011 20:36:44 +0100 (MET)

> exactly what DNSSEC is supposed to detect.  What's the problem?

There may be too many non-malicous middleboxes that perform DNS-MITM
as a service (as recursive resolver or forwarding resolver) on
network edges in the installed base.  The use of DHCP is extremely common.

The only situation when I would actively support aborting the
connection for "bogus" is when the entire set of DNS records
has been conveyed by the server to the client in-band with a TLS
extension.  This is the situation where a reliable transport
is used end-to-end, and the server can be held responsible for
providing incorrect data.

But even in that situation there is a huge caveat: What about root
key roll-over?  How will a client that is behind a dense middle-box
be able to roll the DNS root key?

> and DANE isn't creating a new interop problem.

This particular discussion is about usage types 0/1 that require
that the servers certificate can be successfully validated under
the TLS X.509 PKI and the server endpoint identity match succeeds.

The hotel networks (and firewalled company networks) may be permitting
outbound access to port 443 in addition to accessing port 80.
If adding support for DANE creates new interop problem, because
of DANE not being able to obtain all necessary DNS records to reliably
perform a validation, then we're doing the users a disservice
(they will either switch it off entirely or be desensitized).

And if that happens often enough, then users will be sufficiently
conditioned to either regularly ignore DANE-related warnings or
entirely switch it off, with the effect that DANE validation failures
will be ignored, even for DNSSEC secure results.

-Martin

---

From: Jim Reid <[email-masked]>
Date: Thu, 1 Dec 2011 20:08:06 +0000

On 1 Dec 2011, at 19:36, Martin Rex wrote:

> How will a client that is behind a dense middle-box be able to roll  
> the DNS root key?

This has nothing to do with this WG. Please ask in dsnop: that's the  
right place to discuss the operational issues surrounding DNSSEC  
deployment and validation.

There are essentially two answers to your question. The first is move  
the client to a network that has working DNS. [Which may well be  
easier said than done.] This is no different from how the world  
already has to deal with middleboxes that mess up DNS packets. The  
second answer would be for the client to disable DNSSEC validation,  
slurp the new key and check it somehow by some out of band means --  
handwave, handwave! -- do a manual rollover and then switch DNSSEC  
validation back on again. For dumb devices, that might well be  
achieved by a hard reset of the firmware or something lke that.

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2011 21:16:11 +0100 (MET)

> the dnsext and dnsop working groups.

They _already_ did.  But the current proposals in DANE do not
IMO not account for it.

http://tools.ietf.org/html/rfc4033#section-6

   If a security-aware resolver is separated from the relevant
   authoritative name servers by a recursive name server or by any sort
   of intermediary device that acts as a proxy for DNS, and if the
   recursive name server or intermediary device is not security-aware,
   the security-aware resolver may not be capable of operating in a
   secure mode.  For example, if a security-aware resolver's packets are
   routed through a network address translation (NAT) device that
   includes a DNS proxy that is not security-aware, the security-aware
   resolver may find it difficult or impossible to obtain or validate
   signed DNS data.  The security-aware resolver may have a particularly
   difficult time obtaining DS RRs in such a case, as DS RRs do not
   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
   that this problem is not specific to NATs: any security-oblivious DNS
   software of any kind between the security-aware resolver and the
   authoritative name servers will interfere with DNSSEC.

   If a security-aware resolver must rely on an unsigned zone or a name
   server that is not security aware, the resolver may not be able to
   validate DNS responses and will need a local policy on whether to
   accept unverified responses.

Not being able to access a Web-Server with a non-PKIX cert (usage type 2)
without DANE-warning behind a DNS-proxy is not a new interop problem,
just the lack of a new feature.  Newly being harassed with warnings
when accessing a Web-Server with a PKIX-validating server cert
(usage type 0/1) as soon as the DNS admin enables DNSSEC for the zone
will be a *NEW* interop problem created by DANE if it recommends
to abort on "Bogus".

This could actually amount to a real deterrent of further DNSSEC
deployment if we define DANE this way and browsers add support for DANE.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2011 21:21:54 +0100 (MET)

> deployment and validation.

Not being able to roll the root key will lead to "bogus" state,
for which DANE is trying to specify "ABORT".

I disagree that this is a problem of other WGs.  IMHO this is a
pure DANE problem not following the advice from the designers
of that technology.

> achieved by a hard reset of the firmware or something lke that.

IMHO obtaining full DNS transparency has the same complexity and
likelyhood to happen quickly as IPv6 connectivity for all home customers.
Both will require replacement of the customer premises equiment (CPE),
often a router attached to or integrated with a DSL modem.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Dec 2011 15:46:00 -0500

On Thu, Dec 01, 2011 at 09:16:11PM +0100, Martin Rex wrote:

> just the lack of a new feature.

Yes.

> Newly being harassed with warnings

Sure.  So if you're one of the people faced with this problem, and you
are on a broken network, turn off DNSSEC validation.  DANE will say
"can't use TLSA" and your life is good.  It's not like the DNSSEC
validation was doing you any good anyway.

> deployment if we define DANE this way and browsers add support for DANE.

If you are validating behind a broken proxy, DANE will not be the only
thing that doesn't work.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Dec 2011 15:59:44 -0500

> often a router attached to or integrated with a DSL modem.

Things might not be quite as bad as that, although there are certainly
problems.  We have a little bit of information, however:

http://www.icann.org/en/committees/security/sac035.pdf

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2011 22:10:42 +0100 (MET)

> validation was doing you any good anyway.

Users could be easily compelled to believe that they are on a broken network
and switch DANE off.

If that is turned off once, it will often not be turned back on again.

How about mobile nodes that cache DNSSEC responses and that roam
between networks with dense DNS-proxies and networks with well-behaved
DNS-proxies?  Basically all mobile nodes will be using DHCP and use
the recursive DNS resolver specified in the DHCP lease.

What about alternative transports for DNS records that may be available
for a _subset_ of servers (like in-band through a TLS extension)?

> If you are validating behind a broken proxy, DANE will not be the only

There are *lots* of these broken DNS-proxies, but currently there are
*NO* such interop problems.  Those "broken" DNS-proxies turned out
to be good-enough for original DNS.  Just as IPv4 turned out to be
good-enough for most home users and most manufacturers of
home entertainment equipment.  (I purchased a brand-new LED-LCD TV from
Sony slightly more than a year ago.  It supports only IPv4.)

It would be ostrich-like to ignore the limitations of the real world
and the installed base.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 1 Dec 2011 14:06:18 -0800

I understand what you're trying to argue for here, but the problem is,
any attacker who is in a position to mount one of the attacks that
type 0/1 TLSA records are meant to thwart, is also in a position to
degrade DNSSEC service!  The only way we can claim that DANE provides
an actual, in-practice security improvement over the status quo is if
we don't let the attacker win when they do that, and that means BOGUS
has to mean fail the TLS handshake.  And I'm coming around to the
notion we need to do it for INDETERMINATE too.

Deployment and interop concerns like the ones you are raising are
valid concerns - but we can't let them trump the security properties
we are trying to deliver.  Maybe that means DANE is useless in the
wild - but if so, that's a better outcome than a widely deployed
system that makes the existing trainwreck even worse.

zw

---

From: Martin Rex <[email-masked]>
Date: Fri, 2 Dec 2011 00:49:33 +0100 (MET)

> system that makes the existing trainwreck even worse.

Actually, I am very concerned about the broader security aspect
of the approach you're calling for.

Unhampered DNS access is something we *KNOW* does not currently
exist in non-marginal areas of the internet.  And even if it did
exist, DNS has never been known to be a 100% accurate system.
The reason why it works for the most part is that 100% accuracy
has never been required.  DNS has traditionally been quite
fault-tolerant, which is the reason why there are so many
DNS-proxies in the installed base which will impair DNSSEC
and DANE.

So the issue we're going to be faced with are "false negatives",
which DNSSEC calls "Bogus".

Sensibly dealing with false negatives would mean to make better use
of caching _valid_ DNS records and using experiences from previous
encounters ("soft" cert pinning), which we can update when receiving
data securely, and reuse if DNS lookup ends with "bogus".

But what you're proposing is a Zero-tolerance policy.

  http://www.schneier.com/blog/archives/2009/11/zero-tolerance.html

With the amount of "false alarms" that are to be expected in the
installed base, it will become trivial for an attacker to create
the appearance of a false positive and coerce a large part of the users
to completely disable DANE checking.

  http://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf

I think this is a bad idea.

YMMV.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Dec 2011 00:56:35 +0000

On 1 Dec 2011, at 22:06, Zack Weinberg <[email-masked]> wrote:

> and that means BOGUS

Indeterminate means the client has no trust anchor covering the zone. It is unreasonable to break a server when the client has new software with an old configuration. I think you wanted to say insecure, which means the chain of trust is deliberately incomplete, since that might imply a misconfiguration. But this can legitimately occur if the service provider is relying on an alternate chain of trust, eg DLV or a private trust anchor. So again I think you are wrong.

Tony.

---

From: Martin Rex <[email-masked]>
Date: Fri, 2 Dec 2011 03:49:18 +0100 (MET)

> http://www.icann.org/en/committees/security/sac035.pdf

Admittedly, I stopped doing DNS-admin stuff >12 years ago and have
zero experience with DNSSEC.  I did not notice any NSEC/NSEC3
proof-of-nonexistence tests in that document.  And unfortunately
it does not contain a simple dig-based shell script that I could
just copy&paste and run in my various environments to see how
badly the middleboxes on my path would interfere with DNSSEC lookups.

How common is the use of NSEC/NSEC3 actually in DNS zones that
have DNSSEC enabled?  Without a proof-of-nonexistence, an attacker
should be able to force "indeterminate" status (absence of TLSA records),
I assume.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Dec 2011 14:02:54 +1100

In message <[email-masked]>, Martin Rex writes
> should be able to force "indeterminate" status (absence of TLSA records),

All DNSSEC signed zones have NSEC/NSEC3 records.  The signers don't
produce zones without them.  Validators would be throwing errors
all the time without them.  Even some positive answers need NSEC/NSEC3
records in the responses.

If you don't have NSEC/NSEC3 records in a negative response then
the answer is bogus not indeterminate.

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

---

From: Scott Schmit <[email-masked]>
Date: Thu, 1 Dec 2011 22:45:05 -0500

> Users could be easily compelled to believe that they are on a broken network

If the only thing validating DNSSEC is DANE, sure. If the system
resolver is validating DNSSEC, nothing will work, as the root is signed.

If you're suggesting that DNSSEC is undeployable because of broken
networks, then this WG is wasting its time. For what it's worth, since
the root has been signed, I've noticed a trend in hotel networks away
from hijacking DNS and towards hijacking IP instead. If enough stuff
breaks, the middleboxes will eventually be forced to adapt.

Meanwhile, future drafts can work on stapling, etc.

-- 
Scott Schmit

---

From: Scott Schmit <[email-masked]>
Date: Thu, 1 Dec 2011 22:53:37 -0500

On Fri, Dec 02, 2011 at 12:56:35AM +0000, Tony Finch wrote:
> Indeterminate means the client has no trust anchor covering the zone.
> It is unreasonable to break a server when the client has new software
> with an old configuration. I think you wanted to say insecure, which
> means the chain of trust is deliberately incomplete, since that might
> imply a misconfiguration. But this can legitimately occur if the
> service provider is relying on an alternate chain of trust, eg DLV or
> a private trust anchor. So again I think you are wrong.

It can also happen if the zone is in the middle of switching from
insecure to secure. You want to add the DS after the unsigned records
have expired out of the caches or you'll go bogus until they do.

-- 
Scott Schmit

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Dec 2011 15:23:33 +1100

> have expired out of the caches or you'll go bogus until they do.

There are lots of ways that you can mis-manage zones.  DNSSEC is
more sensitive to mis-management.  That however is not a reason to
not use DNSSEC or to not use DANE.  It is possible to switch from
insecure to secure and secure to insecure without validators returning
bogus.  We have lots of operational experience with doing so with
some of the biggest zones on the planet.

> -- > Scott Schmit

---

From: Scott Schmit <[email-masked]>
Date: Thu, 1 Dec 2011 23:56:05 -0500

> some of the biggest zones on the planet.

Sorry, I wasn't clear. I was trying to point out that as a zone
transitions (properly), it will go from insecure to indeterminate (when
the zone gets signed, but the DS record is not yet available) to secure
(when the DS record is deployed). So, being indeterminate is a
legitimate state, even if one ignores DLV, etc. At no point is the zone
bogus, nor should DANE treat it that way.

As to TLSA records, if they're deployed before the zone is signed,
they'll go through the same progression.

-- 
Scott Schmit

---

From: "Krishnaswamy, Suresh" <[email-masked]>
Date: Fri, 2 Dec 2011 15:08:43 +0000

> http://www.icann.org/en/committees/security/sac035.pdf

There's one differentiator in this study that I wanted to focus on, namely that most middle-boxes are shown to _route_ DNS traffic through them without any problems. Extrapolating further, middle-boxes should not (are less likely to) interfere with queries that originate from a validating stub resolver/validating name server that operates within/in proximity to the client. I run a DNSSEC-enabled version of firefox routinely - behind various middle-boxes - and do in fact see evidence of this fact.  

It seems to me, as much as I feel uncomfortable saying it, that there might be a reason to define a policy knob that controls the manner in which DANE handles the BOGUS condition. If the BOGUS condition was determined locally (through a validating stub resolver or a validating name server running at 127.0.0.1), we would fail-close; if the BOGUS condition was determined through the error code, we'd fail-degrade.

Suresh

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Dec 2011 15:41:41 +0000

> It seems to me, as much as I feel uncomfortable saying it, that there
> might be a reason to define a policy knob that controls the manner in
> which DANE handles the BOGUS condition. If the BOGUS condition was
> determined locally (through a validating stub resolver or a validating
> name server running at 127.0.0.1), we would fail-close; if the BOGUS
> condition was determined through the error code, we'd fail-degrade.

This is a job for software like dnssec-trigger.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Westerly 4 in south at first, otherwise northerly 5 to 7. Rough or
very rough but moderate in south at first. Showers. Moderate or good.