Subject: [dane] DANE and CT

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Nov 2012 15:48:22 +0000

At the CT BoF the question was raised: what about DANE?

Which is a good question. So, I think Google is prepared to
contemplate running a CT log for DANE, but this leaves some
questions...

a) What would we log? DNSSEC keys as well as certs? Only DNSSEC keys?
Something else?

b) How do we prevent the log getting spammed out of existence as soon
as it becomes useful?

c) When someone observes badness in the log, what do they do about it?

I do not intend to drive the answers to these questions, but if
someone supplies them I will certainly consider running a DANE log.

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Nov 2012 16:02:09 +0000

> contemplate running a CT log for DANE, but this leaves some

What problem would CT for DANE be aiming to fix?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Nov 2012 16:05:24 +0000

> What problem would CT for DANE be aiming to fix?

By all means add that to the list of questions :-)

But I assume the same problem CT already fixes: misissuance of certs
(which in the DNSSEC world I guess mostly boils down to bad
delegation).

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Nov 2012 11:28:35 -0500

> What problem would CT for DANE be aiming to fix?

If I run example.com and someone managed to generate / publish a TLSA record for that I'd sure like to know about it. 
Yes, I should be able to simply check myself (and presumably a malicious actor wouldn't submit it to the log :-)), but it seem like it couldn't hurt[0]

Also, as a relying party, if I'm checking / relying on CT this gives me additional information - if the cert / TLSSA record do not match the published stuff in the log I may have evidence that shenanigans are afoot.

Yes, there is a fair bit of detail still to be worked out (what do you *do* if they don't match? what if a DANE user simply doesn't want to publish and the world moves to enforced CT?), the "it seems like it can't hurt" feels scary, and so needs more thought, but to me CT and DANE seem complementary, not competing technologies…

W
[0]: Famous last words!

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

--
Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Nov 2012 11:30:31 -0500 (EST)

> (which in the DNSSEC world I guess mostly boils down to bad

Does that make sense though? With RRSIG validity times and TTL's you
can set your "damange period" as small as you want. There is no issue
like with certificates where your credentials can be abused for up to
12 months.

The only use I could see is as an alternative mechanism to transfer these
records into the application that does not require a clean DNS transport.

I think CT is a bandaid for PKIX that does not apply to DANE.

I think the problem with DANE/DNSSEC right now is the additional latency
and dns transport issues (hotspots, VPN, etc) but I don't think CT is
very well suited to address those.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Nov 2012 16:35:31 +0000

> very well suited to address those.

a) Why would an attacker use your validity times?

b) Weren't you amongst those asking for CT to support DANE during the BoF?

I disagree that CT is a bandaid for anything, BTW - it is a useful
mechanism in its own right.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 14 Nov 2012 11:37:17 -0500

> I think CT is a bandaid for PKIX that does not apply to DANE.

Perhaps not DANE - but DNSSEC.  PKIX allows N CAs to issue unlimited
trusted certs for your domain.  DNSSEC allows 1 TLD to issue unlimited
trusted signing keys for your domain.  Maybe it's the KSK that should go
into a log?

-tom

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Nov 2012 17:02:43 +0000

Warren Kumari <[email-masked]> wrote:
>
> If I run example.com and someone managed to generate / publish a TLSA
> record for that I'd sure like to know about it.

Right. But in PKIX a mis-issued certificate has nothing to do with your
own infrastructure, whereas with DANE it implies that your infrastructure
(or the infrastructure of your DNS service providers) has been
compromised.

I'm a bit worried about the operational implications: PKIX CT is extra
work for CAs, but DANE CT is extra work for everyone.

So I'm skeptical that the cost/benefit tradeoff is positive.

Tony.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Nov 2012 17:07:58 +0000

> (or the infrastructure of your DNS service providers) has been

Isn't the infrastructure of your DNS service providers nothing to do
with your own infrastructure? Not to mention your TLD's
infrastructure, and that of all of their registrars (and, presumably,
DNS service providers)?

> work for CAs, but DANE CT is extra work for everyone.

Only everyone who uses keys, and they've already signed up for quite a
lot of work.

> So I'm skeptical that the cost/benefit tradeoff is positive.

I am unconvinced by your argument.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 14 Nov 2012 12:29:50 -0500

> infrastructure, and that of all of their registrars (and, presumably,

One critical difference is that with DANE, I can query the DNSSEC
delegation chain myself and detect whether my TLD has installed a
bogus DS record and take action. I cannot today detect a bogus 
X.509 cert by myself. I think this makes a CT like scheme less necessary 
for DANE.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 14 Nov 2012 12:51:04 -0500

> X.509 cert by myself. I think this makes a CT like scheme less necessary

I can query my server on port 443 and see if there is a bogus certificate.
 The lack of a bogus certificate in a response to a single query does not
mean there is not a valid attacker-controlled signature chain an attacker
could send to attack a user - whether that signature chain is of PKIX
signatures or DNSSEC signatures.

-tom

---

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Nov 2012 17:56:24 +0000

> X.509 cert by myself. I think this makes a CT like scheme less necessary

You can't detect a bogus X.509 cert because you can't connect to the
server serving it, presumably. What magic allows you to perform this
trick for DNS but not HTTPS?

---

From: Carl Wallace <[email-masked]>
Date: Wed, 14 Nov 2012 12:57:06 -0500

On 11/14/12 11:30 AM, "Paul Wouters" <[email-masked]> wrote:

<snip>
>I think CT is a bandaid for PKIX that does not apply to DANE.

I thought the point was that DANE would not be allowed to do "an end run"
around CT so logging DANE stuff was necessary, not that DANE necessarily
had the same needs as the web PKI.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 14 Nov 2012 13:14:37 -0500

> trick for DNS but not HTTPS?

For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC 
authentication chain, not the existence of a fraudulently issued 
certificate on some attacker's server.

If the DNSSEC chain is intact, then presumably DANE aware clients 
will properly authenticate the TLSA record before accepting the server 
certificate. I admit that's a mighty presumption today, but we'll see ...

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 14 Nov 2012 16:48:59 -0200

> > On Wed, 14 Nov 2012, Ben Laurie wrote:
...
> a) Why would an attacker use your validity times?

What do you mean? What is your attack scenario? This thread quickly
starts to move to a marshy soil.

Fred

---

From: Leif Johansson <[email-masked]>
Date: Wed, 14 Nov 2012 23:52:21 +0100

> What problem would CT for DANE be aiming to fix?
You're sending a chain to the log server for CT. The chain must be
rooted at something that is reasonably widely trusted (to avoid
spamming). For DANE, that means extending the chain through
DNSSEC up to the DNS root.

my 5c

---

From: Leif Johansson <[email-masked]>
Date: Wed, 14 Nov 2012 23:53:56 +0100

> like with certificates where your credentials can be abused for up to
You still need to detect the attack, right? DANE may help you mitigate
the attack but it won't help you detect it.

        Cheers Leif

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 14 Nov 2012 21:28:38 -0200

> the attack but it won't help you detect it.

Respected the DNSSEC "grand scheme of things" a relying party will
definitely detect it, perhaps not the owner of the zone. Is that what
you meant?

Fred

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Nov 2012 08:54:20 +0100

> definitely detect it, perhaps not the owner of the zone. Is that what
yep

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Nov 2012 08:02:04 -0500

> What problem would CT for DANE be aiming to fix?

I see a number of issues that need fixing:

1) Domain hijacking

DANE certificates are only as secure as the DNS names they are attached to.
DNS hijacking occurs at a rate well in excess of 10,000 names a year and is
probably much much higher if we could get better numbers.

At present the DNS name owner (and it is the owner, regardless of what
idiot lawyers claim) has to rely on their registrar to be competent and on
the processes at the registry and to a certain extent on the honesty of
other registrars. This whole area is essentially opaque, there is no
documentation for most of the processes on which businesses are forced to
rely.

2) Root jacking

Russia and China are just not going to be recognizing the ICANN roots
dudes. They have been telling everyone who will listen that they are going
to fork the root and they have a big enough fraction of the population of
the planet to make it stick.

So people can do the ostrich head in the sand thing or they can anticipate
this attack and think about ways to neutralize it.

3) Demonstrate continuity

In the case that a DNS name changes hands I do not necessarily want to be
sending the new information the confidential data I would have sent the old
one. Lacking the ability to establish an external validation of the source,
this means I am much more interested in determining the lineage of
credentials.

Or it could just be that the DANE people have created an absolutely perfect
system that is beyond any possible reproach and the fact that nobody seems
to be implementing it beyond limited scale trials and plugins is due to the
inability of everyone else to fully appreciate their awesomeness.

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Nov 2012 07:46:47 -0800

> certificate. I admit that's a mighty presumption today, but we'll see ...

This is an excellent summary of the scenario.

However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record.

For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B.

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Thu, 15 Nov 2012 13:43:24 -0500

> For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of reque…

Good point. An auditable log of DS/SEP key chains would seem to
be useful for this.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Nov 2012 15:10:51 -0500 (EST)

> a) Why would an attacker use your validity times?

Because there are DNSSEC keys to back the time slots used, and
without it, the data can and should be rejected.

> b) Weren't you amongst those asking for CT to support DANE during the BoF?

I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS
certificate market where I have to pay $10-$150 a year to be "accepted"
in browsers via CT. What I understood was that browser vendors that
were looking at CT and DANE would specifically not be supoprted. The
first thought was to have a DANE backed CT that could be configured,
purely to get the DANE information (valid key + TTL/RRSIG info) into
the browsers that don't support or want to support DNSSEC (chains).

But the DANE/DNSSEC information does not need an publicly shared audit
log. Its current up to date  validity is available in the DNS at all
times, cached and distributed.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Nov 2012 15:32:47 -0500 (EST)

> For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of reque…

Interesting. I had not considered this because a big difference is that
such rogue DNS records would not be contained/targetted. The forged DS
created by the parent would quickly expose the parent, and I doubt the
parents would want that reputation damage. Unless they are totalitarian
governments, but unlike phb, I give up any kind of using the internet
against advisaries that are physically in the path - it just ends up
with you refusing to be lied to and not connecting, or going along with
their lies and getting eavesdropped.

But I'm not sure how CT would see the difference between me logging
in to my registrar interface and updating the DS record, someone else
using my credentials to do the same without my knowledge, or the registry
going rogue. The way PKIX-CT does this is via some financial transaction
pretending to convey trust and authority and a credit card audit trail.
It fails for the common user precisely because it costs money, and
today's criminals have more money to invest compared to the average
internet user.

I also don't see how TACK addresses this either, with their complicated
pinning schemes that are just many different ways of shooting yourself
in the foot, without adding anything to the DANE pinning method (apart
from relying on verisign to not forfeit their root zone contract to sign
custom data for anyone)

So I think CT could be used as DNSSEC/DANE history audit log, but IMHO
the main asset of something like CT based DANE is purely as a better transport
layer for DNSSEC - not as a replacement for DANE/DNSSEC.

DNSSEC points to the publisher, who is defined as always right (even if
they are wrong because they are sloppy or have a gun pointed at their
heads)

Paul

---

From: Danny McPherson <[email-masked]>
Date: Thu, 15 Nov 2012 17:57:45 -0500

On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote:

> 
> DANE certificates are only as secure as the DNS names they are attached to. DNS hijacking occurs at a rate well in excess of 10,000 names a year and is probably much much higher if we could get better numbers.

PHB - do you have a citation qualifying this?

Thanks, 

-danny

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Nov 2012 19:14:21 -0500

On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson <[email-masked]> wrote:

> > DANE certificates are only as secure as the DNS names they are attached
> to. DNS hijacking occurs at a rate well in excess of 10,000 names a year
> and is probably much much higher if we could get better numbers.
>

Not one I can share. But it seemed at the lower bound to me given the
number of sites I use that have been hijacked recently.

You folk should have much more accurate figures. Care to share?

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 15 Nov 2012 19:33:21 -0500

On 15/11/2012 19:14, Phillip Hallam-Baker wrote:
>
>
> On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>      > DANE certificates are only as secure as the DNS names they are
>     attached to. DNS hijacking occurs at a rate well in excess of 10,000
>     names a year and is probably much much higher if we could get better
>     numbers.
>

Can you give us any indication if this is problem across major TLD's or 
limited to a few.
	
	thanks
	Olafur

---

From: Danny McPherson <[email-masked]>
Date: Thu, 15 Nov 2012 19:37:20 -0500

> You folk should have much more accurate figures. Care to share? 

Nope, we're just the registry operator, most of these issues are resolved with the registrars, hence my query.

Thanks, 

-danny

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Nov 2012 23:34:15 -0500

> Can you give us any indication if this is problem across major TLD's or

Given that all the cases I have seen have been hacks on the registrar, I
can't see why it would be limited to one TLD. But very few of the sites I
use are outside .com

What I am referring to here is what happened to therpf.com recently when
their domain name was hijacked by some squatter who then inserted a proxy
to the real site but serving their own ads (plus malware no doubt).
Wikipedia refers to it as Domain Hijacking rather than DNS, but that is
what I meant.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 16 Nov 2012 11:23:09 +0000

> without it, the data can and should be rejected.

This argument is circular: clearly if no-one ever gets control of keys
for your domain, you don't have a problem. Validity times are
irrelevant.

If someone does get control, they control validity times, no?

> times, cached and distributed.

You have a lot of faith in a mechanism that is not designed to provide
a globally consistent view. How does DNS prevent bad actors from
showing local views of the DNS? (Hint: it doesn't).

This is precisely what CT does, and is exactly the value it adds to
this kind of system.

As for CT vs DANE, it is precisely because DNS does not provide a
robust infrastructure that DANE cannot be allowed to override CT. This
can be fixed by making DANE use some kind of equivalently strong
transparency. I agree with others that this is probably better applied
to DS records than to TLSA records.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 16 Nov 2012 11:26:14 +0000

On 15 November 2012 20:32, Paul Wouters <[email-masked]> wrote:
>> However, that's not exactly what Ben is asking about. CT-for-PKIX is about
>> "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is
>> about "did a server in the hierarchy above the leaf include a DS it should
>> not have". In the latter case, those rogue DS records might not be
>> detectable to the party with the leaf record.
>>
>> For example, assume the domain name example.newtld. The owner of example
>> has put DS record A in the newtld zone. If the owner of newtld goes rogue
>> and shows DS record B to a limited number of requests (such as to a
>> particular geographic region or set of network addresses), the party with
>> the private key associated with B can spoof example, and the owner of
>> example would not know unless he could see B.
>
>

Incorrect: CT provides a globally verifiable audit trail - the
exchange of money is irrelevant.

CT does not see the difference between you logging in to your
registrar interface and updating the DS record, someone else using
your credentials to do the same without your knowledge, or the
registry going rogue. What it does it make all of these visible to
you. Then it is up to you (or anyone else) to spot the abuse and do
something about it.

> layer for DNSSEC - not as a replacement for DANE/DNSSEC.

CT does not replace DNSSEC (or PKIX), it does as you say: provides an audit log.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Nov 2012 13:49:26 -0500 (EST)

> If someone does get control, they control validity times, no?

If someone obtains your private keys, there is no need to forge anything
or issue any new certificates, they just run a copy of your private
key/cert on their MITM box. CT can't help you there either. If attackers
get your private DNSSEC keys (which shouldn't even be online, and surely
much harder to obtain compared to the TLS private key) you are lost.

> showing local views of the DNS? (Hint: it doesn't).

The root key protects me against that. And the TLD key. Sure, if I'm
using some untrusted national TLD which might be overwriting my parent
NS/DS set, again you are in a no-win situation. Best you can do is
monitor your own zone, and possible carry your own domain's trust
anchors with you. And these same players would simply prevent you from
accessing the CT services as well.

> robust infrastructure that DANE cannot be allowed to override CT.

So Diginotar will submit a new cert for me to the CT, and we're back at
square one?

> This

While I agree that it won't hurt to log and audit DS records to see if
verisign or the USG really is signing their own records with the root or
.com keys, I still believe those two parts are the most secure players
I know to delegate some trust to. The real weak points of DNSSEC will be
the dns operators of the zones and the registrar webgui's for making
zone changes. In fact, I would probably rather trust the root key, then
most CT audit people - and it would come with less false positives due
to the middle man delays.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Nov 2012 13:53:25 -0500 (EST)

> exchange of money is irrelevant.

It is if Google CT only accepts submissions of CAs, and Chrome ships
with the Google CT. It forces me to use CAs.

> you. Then it is up to you (or anyone else) to spot the abuse and do

Which is the exact problem of outsourcing trust vs trusting no one.
People keep insisting they can do both. Adding another "cert patrol"
warning box in my browser isn't going to make users more secure. So what
happens if I update my TLS key? I need to live with a few hours of users
getting told my site is hacked and clicking OK, or do we ignore the
first few hours of a site being compromised?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Nov 2012 11:06:50 -0800

> to DS records than to TLSA records.

Proposal: we take this off the DANE list and keep it on therightkey list, focused on DS instead of DANE. That is, a rogue zone with additional / substitute DS records might affect more than DANE in the future.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Nov 2012 17:40:07 -0500

+1

Paul is right here, the big value in CT is probably applying it as a
reinforcement against people screwing with the DS records or to ensure that
DLV type schemes are not being futzed with.

On Fri, Nov 16, 2012 at 2:06 PM, Paul Hoffman <[email-masked]> wrote:

> Proposal: we take this off the DANE list and keep it on therightkey list,
> focused on DS instead of DANE. That is, a rogue zone with additional /
> substitute DS records might affect more than DANE in the future.
>
> --Paul Hoffman
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

---

From: James Cloos <[email-masked]>
Date: Fri, 16 Nov 2012 19:50:47 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> Proposal: we take this off the DANE list and keep it on therightkey
PH> list, focused on DS instead of DANE.

+1  TLSA is only one relevant vector for dnssec attacks.  Any such
discussion should be more general.  And tracking DS RRs feels like
enough to provide tamper evidence, at least.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Ben Laurie <[email-masked]>
Date: Sat, 17 Nov 2012 10:52:54 +0000

+1