Subject: [keyassure] Bootstrapping Dane Adoption

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 10:17:23 +0100

(just pursuing the conversation on a thread that with a name that is more 
 related to the topic, since this has no more that much to do with publishing
 bare public keys )

On 15 Feb 2011, at 22:58, John Gilmore wrote in the thread archived at
http://www.ietf.org/mail-archive/web/keyassure/current/msg01810.html

>>   I can't remember if in their presentation they tell us how many valid self
>> signed certs they found out there...
> 
> According to Chris Palmer of EFF, the SSL Observatory found 7 million
> self-signed certs (and 4.3 million with other certs).  But none of the
> self-signed certs were considered "valid self-signed certs" because
> the definition of "valid" was "with a valid signature chain, according
> to at least one browser", and of course browsers consider self-signed
> certs invalid.
> 
> It appears that securing your web site with crypto is about three
> times as popular as obtaining a certificate from a certifying
> authority.
> 
> So, providing a simple way in DNS for those 7 million web
> administrators to securely anchor their website's public keys to their
> domain names, without dealing with a certificate authority, would
> provide significant benefits to literally millions of people.

Yes. 

It occurred to me that DNSsec providers could easily bootstrap the
adoption of Dane by pinging port 443 of their clients hosts, getting the 
X509 Cert if it is there, verify it is correct, and if it is self signed
add the cert or public key to the DNSsec entry.

With even a few million such entries it would then be very easy to 
convince browser manufacturers of the use of adding support for DANE.

Henry

> 	John Gilmore

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 07:21:02 -0500

> convince browser manufacturers of the use of adding support for DANE.

Nope, because it would break everyone behind a MITM SSL proxy.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 13:52:51 +0100

> Nope, because it would break everyone behind a MITM SSL proxy.

Ok. So it could automatically alert the user, and ask him if he would
like this to happen by confirming securely his intention. 

Perhaps a link to a browser plugin initially would be useful,
so that people can see where this is leading.

Henry

> AGL

Social Web Architect
http://bblfish.net/

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 08:03:39 -0500

> like this to happen by confirming securely his intention.

Adding more UI warnings is a classic trap that smart people fall into.
Although it suffices for experts, it's worse than useless for 99.9% of
users.

Rather I suspect that the solution will have to be more messy than
this. If we had a list of the Issuer names that MITM boxes used, then
we could skip the check in those cases. But we don't and finding out
will be painful for some users.

Rather I suspect that the answer will be in the form: "If this cert is
accepted by the verifier but is rooted at a non-default CA, then
assume it's a MITM box and skip the check". That's been on my todo
list for a while now in Chrome.

AGL

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 08:39:55 -0500

Presumably the MITM SSL proxy vendors just need to start MITM-ing the DNS traffic now too?

Honestly, this seems like a security plus to me -- out-of-band verification of keys!

--Richard

On Feb 16, 2011, at 7:21 AM, Adam Langley wrote:

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

---

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 14:43:39 +0100

>> like this to happen by confirming securely his intention.

Oops. Sorry I think I sent my reply above too quickly. I was thinking you
were speaking of the DNSsec provider having a MITM problem, and so my solution
was geared towards asking the domain admin to verify that.

But in fact you were thinking of this from the end-user-behind-his-browser
experience, and the issue you are thinking of is not just any MITM TLS proxy, 
but legitimate ones such as those that are behind HTTPS company firewalls. 
As it happens we just had  a discussion of this on the WebID mailing list 

ISSUE-28: "How does the WebID protocol (foaf+ssl) interact with TLS proxies"
           http://www.w3.org/2005/Incubator/webid/track/issues/28

So if I understand correctly from that discussion and thanks to the clear 
contribution by Yngve from Opera ( http://bit.ly/g4jt5P ) companies that
use these proxies would put the proxy root certificate into their employees 
browsers. They would be foolish if they did not, because if they did not
they would be training their users not to take care of security alerts.

What the proposal of allowing people to place self signed certs into DNSsec
using Dane is designed to do, is to allow browsers to distinguish between
the millions of legitimate self signed certs and the non legitimate ones.
As a result browser warnings will be a lot more meaningful.

What you are bringing up is another subset of self signed certificates 
usages: those by legitimate TLS proxies. For those it seems there is
the existing solution described above. Yngve also mentioned something
about "Proxy Certificates" though I don't know much about those. 

> Although it suffices for experts, it's worse than useless for 99.9% of

Yes, sorry. I was not proposing more UI warnings for the browser user.
Rather I was thinking of having the DNS provider send an email suggesting 
to its clients to add public keys using dane to DNSsec.

I was in fact trying to reduce the case of legitimate end user warnings
by allowing the browser to distinguish between legitimate and 
illegitimate self signed certificates by allowing legitimate web sites
to place keys in DNSsec.

> will be painful for some users.

There seems to be something called "Proxy certificates" according to Yngve.
But he did not give further pointers, so I don't know how those work.

> list for a while now in Chrome.

You mean assume it's a Good MITM box and skip the check? That would completely
defeat the whole point of TLS. I think you must be thinking of something else.

Henry

Social Web Architect
http://bblfish.net/

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 16 Feb 2011 09:00:22 -0500

> Presumably the MITM SSL proxy vendors just need to start MITM-ing the DNS traffic now too?

Yep.  Let them fork the world all the way up to the root zone trust
anchor.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 16 Feb 2011 09:33:59 -0500

> defeat the whole point of TLS. I think you must be thinking of something else.

The proposal is to exempt "non-default" trusted CAs from DANE exclusion,
but I don't think "non-default", whatever it means, is what we want.  We
probably want a separate trust bit.  Let's just hope Mozilla doesn't
start handing it out to public CAs.

-- 
Matt

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 09:43:31 -0500

> to its clients to add public keys using dane to DNSsec.

If DNS information is to be used as an additional source of
certificate verification then you have a chicken and egg problem:
  * Sites won't publish the information in DNS because it'll break
capable clients behind MITM proxies.
  * MITM proxies won't change until the pressure is overwhelming.

(`Sites' here means sites that have valid certificate, but are worried
about mis-issuance by CAs, mistaken or otherwise.)

I'm not suggesting that MITM proxies are a good thing but the reality
is that a) they exist in numbers large enough that we can't ignore
them b) they're very slow to change.

> defeat the whole point of TLS. I think you must be thinking of something else.

Yes that's what I'm suggesting as a way to break the deadlock described above.

AGL

---

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 16:34:20 +0100

> capable clients behind MITM proxies.

Why would publishing a public key in DNS break capable clients behind
MITM proxies? 

 1- for current browsers it makes no difference, since they don't look
   in DNS for that information
 2- for the yet to be built browsers it will depend on how MITM proxies 
   work and how the algorithm for chosen for selecting legitimate certificate. 

 How do MITM proxies work? I am told ( http://bit.ly/g4jt5P ) that either
   a. companies simply place the MITM certificate in their employees browsers as trusted root certificates
   b. there seems to be something as a "Proxy Certificates" which I have not enough
      information for.

  So the case we are looking at for the moment is a situation such as 2a, and
the trick is to specify an algorithm where browsers work behind good proxies, but not
behind evil proxies such as the ones in an internet café. We also want browsers
2a to allow legitimate self signed certificates. It seems to me that this is an easy algorithm to write down. The User Agent on receiving a certificate follows this procedure

  Step 1. is this certificate signed by a trusted CA, or can I build a chain to a trusted CA? 
  - If yes, it's a good connection. Proceed with browsing experience.
    Note that since legitimate Proxy certificates appear in the trusted CA list as explained in a above (and I imagine something similar works for what is known as "Proxy Certificates") this deals with legitimate proxies. Illegitimate proxies won't be able to be tied to the trusted CA roots, and the DNS lookup described in step 2 won't work either, so they will fail)
  - else go to 2.
 
  Step 2. Is this a self signed certificate, or one that it makes sense to look up in DNSsec? 
  - If yes, look it up, and if tests succeeds then it's a good connection. Continue with browsing experience. 
  - else show ugly monster to user so he understand this is dangerous.

>  * MITM proxies won't change until the pressure is overwhelming.

I think there is no need for them to change. Well if I thought about it, perhaps I could come up with ways to improve them, but that would be a different topic.

> Yes that's what I'm suggesting as a way to break the deadlock described above.

So how does that not break all of TLS at the same time?

Henry

Social Web Architect
http://bblfish.net/

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 10:44:06 -0500

>  - If yes, it's a good connection. Proceed with browsing experience.

We're solving different problems. You want to enable certificates to
validate without being CA signed. I understand that, although, given
that StartCom gives out free certs I feel that this is mostly a large
organisation problem.

I'm talking about sites which are worried about CAs misissuing
certificates. Either because the CA was fooled (*), or because an
intermediate CA cert was misused.

These sites have CA signed certs but they want to publish information
which excludes other CAs, or other certificates. That leads to the
chicken-and-egg problem that I described.

AGL

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Feb 2011 11:23:59 -0500 (EST)

> Nope, because it would break everyone behind a MITM SSL proxy.

Couldn't the MITM SSL proxy register their cert in the DNS entry associated
with their name or reverse ? That way, it becomes a "DANE certified" MITM,
so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then
don't warn the user...

Now people with a MITM SSL proxy are protected against other MITM entities.

Paul

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 11:29:22 -0500

> Now people with a MITM SSL proxy are protected against other MITM entities.

Pressure can be applied to the vendors to make changes but, in my
experience, they move very slowly and customer update firmware even
more slowly.

In order to get off the ground I feel that it's important that clients
not be broken so that sites don't feel pressure not to publish DNS
cert information.

AGL

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Feb 2011 11:39:01 -0500 (EST)

> experience, they move very slowly and customer update firmware even

But it is not the vendors that would need to make that change? It's just the
browser people and the entity deploying SSL proxies?

> not be broken so that sites don't feel pressure not to publish DNS

You could disable DANE lookups if a proxy for SSL is configured?

I guess that leaves transparent SSL proxies still as a problem.

Paul

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 11:48:29 -0500

> browser people and the entity deploying SSL proxies?

Ah, I understand what you are suggesting. Indeed you could do that
with just action by the proxy admins. However, I still feel that those
people will be very slow in changing.

> I guess that leaves transparent SSL proxies still as a problem.

Skipping additional checks when a proxy is configured is a good idea.
For transparent proxies I suspect that we'll need to skip them when
the certificate is correctly signed by a root which has been added to
the system.

But, in the end, we'll have to try our best and discover what works
via bug reports.

AGL

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 11:50:15 -0500

Transparent SSL proxies really are a problem from a security perspective.  It's always a bad idea to design protocols that accommodate them without client configuration -- because then you end up accommodating malicious MitM entities as well.

What is worth thinking through is what sort of client configuration changes are necessary to accommodate transparent SSL proxies.  In the current, X.509-based environment, the critical change is to add a trust anchor to the client SSL verification system.  This enables the proxy (holding the private key that goes with the TA) to issue certs for sites that clients visit.

The corresponding process for DANE would just change X.509 to DNSSEC: Clients would have an additional DNSSEC TA (i.e., in addition to the root), so that the proxy could assert trust chains that bind keys under its control to names that clients are interested in.

I wasn't kidding when I said that proxies would need to MitM the DNS traffic as well :)

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 11:51:27 -0500

Of course, Adam's idea to allow locally-configured X.509 TAs to override DANE would work as well.  That's just forcing the client back into the old world, which is a good thing in this case.
--Richard

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Feb 2011 12:31:50 -0500 (EST)

> the certificate is correctly signed by a root which has been added to

This reduces DANE back to the case where every CA on the planet can MITM.
That would not be good. At least make it a config option that can be
changed, and then we can argue about when is the right time to switch it.

Paul

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 13:05:53 -0500

> changed, and then we can argue about when is the right time to switch it.

I don't believe that it does. What I'm suggesting is this:

The set of root CAs shipped by default for Firefox and Microsoft is
known. We know that these aren't MITM certificates. So, if we get a CA
certificate rooted at one of those certs, and information from the DNS
which contradicts that, we can reject the certificate. This means that
you can't fool a CA into issuing a certificate and attack users.

However, if a certificate validates, but isn't rooted at a standard
root, then it's been signed by a root that has been manually added. In
this case, there's a good chance that it's a MITM proxy and we skip
the DNS check. Thus the only roots which can override DNS information
are those which have been manually added.

It will fail if there are MITM proxies that use intermediate CA
certificates that root at a standard root. I very much hope, for many
reasons, that such a proxy doesn't exist.

AGL

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Feb 2011 13:51:35 -0500 (EST)

> are those which have been manually added.

Ahh I see. I did not realise the browsers kept a difference between manually
added and shipped per default. This would work then, except if the MITM
proxy is signed with public CA shipped with a browser. Do people not do that?
I thought perhaps MITM proxies did this to already reduce popups.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Feb 2011 21:19:18 +0200

> I thought perhaps MITM proxies did this to already reduce popups.

No, the commercial CAs don't sell you certificates with Basic Constraints set to true. the MitM proxies have their own CA certificates, and the user (or her administrator) have to install the MitM certificate to get it to work. That way they know that they can be attacked.

It's also news to me that browsers differentiate between TAs that were shipped as opposed to TAs that were added.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Feb 2011 21:24:02 +0200

> people will be very slow in changing.

I disagree. While my company doesn't make SSL proxies, we do make firewalls, and it's always up to us to accommodate whatever browsers customers are using. 10 years ago it turned out that our firewall was blocking Netscape browsers on Mac OS 9.2. We had to change our firewall.

So if some new version of a popular browser starts getting blocked behind the SSL proxy, then the proxy vendor will be pressured to fix it. It's a competitive market, and you don't get to say, "oh, we don't support Chrome 11. Maybe we will next year"

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Feb 2011 14:34:43 -0500

On Wed, Feb 16, 2011 at 11:50:15AM -0500, Richard L. Barnes wrote:
> 
> The corresponding process for DANE would just change X.509 to
> DNSSEC: Clients would have an additional DNSSEC TA (i.e., in
> addition to the root), so that the proxy could assert trust chains
> that bind keys under its control to names that clients are
> interested in.
> 

You're suggesting that the client uses an intermediate resolver for
which it has a TA configured.  The intermediate resolver, when
responding to {all|some class of} queries, intercepts the answers,
creates new RRSIGs and DS records and so on, and synthesizes those as
part of the answer returned to the client?  I guess if you reproduce
the whole chain of trust all the way down, it could work.  I'd want to
work through it completely.  But do I have the idea right?

A

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

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Feb 2011 21:34:52 +0100 (MET)

> I guess that leaves transparent SSL proxies still as a problem.

Transparent SSL proxies ought not to be a problem, since they do
not affect DNS lookups at all.

But _configured_ SSL proxies may be an indicator that a browser
itself lives in a seperate DNS universe (not that uncommon in
sensibly firewalled company networks), so that no DNS or DNSSEC
records from the internet are accessible for the browser.

There used to be a number of broken clients, though being
HTTP or HTTPS proxy capable, were still trying to resolve hostnames
locally even when connecting through the proxy and failed
badly if the DNS lookup failed.  It appeared to be common
breakage in Java applets a decade ago, but it also affected
the OpenSUSE 11.1 network installer.

A common workaround for such breakage is to add the offending
hostname with a random ip to the local hosts file and retry...

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Feb 2011 22:01:56 +0100 (MET)

> work through it completely.  But do I have the idea right?

One possible hack for a HTTP CONNECT proxy would be to perform
all DANE-relevant DNSSEC lookups for the given URL and put the responses
in their entire beauty into Mime-Headers of the HTTP CONNECT response...

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 10:20:43 +1100

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> Transparent SSL proxies really are a problem from a security perspective.  It
> 's always a bad idea to design protocols that accommodate them without client
>  configuration -- because then you end up accommodating malicious MitM entiti
> es as well.
> 
> What is worth thinking through is what sort of client configuration changes a
> re necessary to accommodate transparent SSL proxies.  In the current, X.509-b
> ased environment, the critical change is to add a trust anchor to the client 
> SSL verification system.  This enables the proxy (holding the private key tha
> t goes with the TA) to issue certs for sites that clients visit.
> 
> The corresponding process for DANE would just change X.509 to DNSSEC: Clients
>  would have an additional DNSSEC TA (i.e., in addition to the root), so that 
> the proxy could assert trust chains that bind keys under its control to names
>  that clients are interested in.
> 

Adding a alternate root trust anchor won't work.  The root key only
signs the root zone.  99.999% percent of spoofed anwers won't be
from the root zone.

It needs to be a key that is use as a alternative verification
source or you need to trust "AD" and not validate yourself.

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

---

From: John Gilmore <[email-masked]>
Date: Wed, 16 Feb 2011 15:36:53 -0800

> Transparent SSL proxies really are a problem from a security perspective.

If DANE anchoring of SSL is properly implemented, then anyone who
sticks a MITM (of any sort) in the middle is going to have it detected
and rejected.  No communication.  Even if it's corporate policy to
watch everything in the clear in some great-wall-of-Intel or whatever.

When that little LOCK icon turns on, you'll damn well know that you're
talking to the server of the domain name you typed - and nobody else.

It could only come from IETF...security protocols that actually work,
despite corporate policies against actual security!

	John

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 17 Feb 2011 00:45:16 -0500

Actually, I don't think it would be that hard to spoof the root zone, assuming your clients are provisioned with an alternate TA (i.e., the one you hold).  

In the worst case, you have to re-sign the root zone, then create keys and signatures down the hierarchy to the record you want to spoof.  

My DNSSEC foo is a little hazy on this one, but I wonder if you could even just return signed records as if they came directly out of the root.  I seem to recall a certain root node doing something like this (returning A records, but no DNSSEC) last March or so.

I'm not saying this is a *good* idea, but technically, it does work.  I'm not that hot on SSL middleboxes either, but they need to be handled properly.

--Richard

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 19:55:36 +1100

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> Actually, I don't think it would be that hard to spoof the root zone, =
> assuming your clients are provisioned with an alternate TA (i.e., the =
> one you hold). =20
> 
> In the worst case, you have to re-sign the root zone, then create keys =
> and signatures down the hierarchy to the record you want to spoof. =20
> 
> My DNSSEC foo is a little hazy on this one, but I wonder if you could =
> even just return signed records as if they came directly out of the =
> root.  I seem to recall a certain root node doing something like this =
> (returning A records, but no DNSSEC) last March or so.
> 
> I'm not saying this is a *good* idea, but technically, it does work.  =
> I'm not that hot on SSL middleboxes either, but they need to be handled =
> properly.
> 
> --Richard

You would have to sign every response and remove all trace of zone
cuts to use normal validators internally.  This assumes that you
want to intercept all communications.  If you just want to intercept
some then you would still need to make those paths appear to be in
the root zone.  You could delegate away the paths you don't care about.

> >=20
> > In message <[email-masked]>, "Richard L. =
> Barnes"=20
> > writes:
> >> Transparent SSL proxies really are a problem from a security =
> perspective.  It
> >> 's always a bad idea to design protocols that accommodate them =
> without client
> >> configuration -- because then you end up accommodating malicious MitM =
> entiti
> >> es as well.
> >>=20
> >> What is worth thinking through is what sort of client configuration =
> changes a
> >> re necessary to accommodate transparent SSL proxies.  In the current, =
> X.509-b
> >> ased environment, the critical change is to add a trust anchor to the =
> client=20
> >> SSL verification system.  This enables the proxy (holding the private =
> key tha
> >>=20
> >> The corresponding process for DANE would just change X.509 to DNSSEC: =
> Clients
> >> would have an additional DNSSEC TA (i.e., in addition to the root), =
> so that=20
> >> the proxy could assert trust chains that bind keys under its control =
> to names
> >>=20
> >> I wasn't kidding when I said that proxies would need to MitM the DNS =
> traffic=20
> >> as well :)
> >>=20
> >> --Richard
> >=20
> >=20
> >=20
> > --=20

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Feb 2011 05:56:10 -0800

On Wed, Feb 16, 2011 at 11:24 AM, Yoav Nir <[email-masked]> wrote:

> I disagree. While my company doesn't make SSL proxies, we do make
> firewalls, and it's always up to us to accommodate whatever browsers
> customers are using. 10 years ago it turned out that our firewall was
> blocking Netscape browsers on Mac OS 9.2. We had to change our firewall.
>
> So if some new version of a popular browser starts getting blocked behind
> the SSL proxy, then the proxy vendor will be pressured to fix it. It's a
> competitive market, and you don't get to say, "oh, we don't support Chrome
> 11. Maybe we will next year"

But you do get to say 'we don't support a specific feature of Chrome 11'.

Having run firewalls as an outsourced service, I know that a huge fraction
of the installed base is misconfigured and has obsolete configurations. A
non trivial fraction of firewalls being brought under management turn out to
be configured for pass through of all protocols (The $250,000 ethernet cable
configuration).

I think we need to have a document that sets out what the specific issues
with these proxies are and we need to decide which to support and which to
not support.

SSL is not 'designed' to prevent MITM attacks, the whole PURPOSE of SSL is
to prevent MITM attacks. So I think we need to decide which issues to
support and which not to support.

I strongly suspect that the MITM proxy ssl capabilities are underspecified
to say the least. They were originally a feature that was thrown into
Netscape Navigator for expediency with zero discussion outside the company.

I know that it is the type of feature that IETF types have traditionally
preferred to ignore. I certainly have felt no inclination to look at that
type of feature. It was put in the specs against my protests as a fait
accompli.

But that is a pretty bad situation from a security point of view and there
is a huge risk here of creating a massive hole in SSL of Kaminsky
proportions if people decide that they can simply follow the same approach
because they have a particular view of what CAs do and they can remove
controls that they personally don't think matter.

I think we are going to either have to decide that this scheme is not going
to support SSL proxies at all or it is going to have to have a first class
mechanism designed to support the SSL proxy use case.

Handwaving arguments about security protocols are a recipe for disaster. In
particular the argument that 'its ok we already do this without disaster'
has led to a number of notorious security protocol failures.

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