Subject: [dane] + add security ... (was : Re: an implementor's comments on DANE)

From: Marc Lampo <[email-masked]>
Date: Fri, 12 Oct 2012 09:28:35 +0200

Before the draft was adopted as RFC I asked how to cope with proxies.

On Sector 2012, last week, I was quite shocked to hear a speaker (also
reading this, I assume) to simply state to get rid of them !
I'd rather see continued work on how to make the principle of DANE
apply/work even in the presence of proxies.

The other security remark is that, in order for the browser to use
info in TLSA record, the host needs access to public DNS.
 (with the use of a proxy, a setup with internal-roots is possible,
internal hosts don't need access to public IP addresses
  if they use proxies)
However, TLSA is not "an address", so access to public DNS is needed.
But that (access to public DNS) allows for new threats in the area of
data leakage !!!
 One can do file transfer, both in and out of a network, using correct
DNS messages, if access to public DNS is available.
   (as I addressed, when still Security Officer for EURid, on CENTR
Security WG meeting in June 2012, in Frankfurt)

In summary :
 Usage of TLSA, in its present form, opens new can of worms.
 Which can only be kept closed if somehow collaboration of DANE (TLSA)
and proxies can be achieved.

Regarding DNSSEC :
do not forget that adding signatures without verifying them is almost useless.
And since *lots* of networks use AD, with its (non DNSSEC capable) DNS
servers, only few users actually benefit, at this moment.
 ("non DNSSEC capable" : since MS DNS does not support a protocol
higher than 5, and treats everything higher as "unsigned":
  + since the root zone uses protocol 8
  --> this comes down to "not capable DNSSEC")

So, wether or not the TLSA record is coming from a signed domain, most
users are not capable of noticing this anyway.

Kind regards,

Marc Lampo

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Oct 2012 09:45:29 +0100

> Before the draft was adopted as RFC I asked how to cope with proxies.

Why are proxies a problem for DANE in particular, rather than TLS in
general?

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: Nicholas Weaver <[email-masked]>
Date: Fri, 12 Oct 2012 09:57:02 +0100

> Why are proxies a problem for DANE in particular, rather than TLS in

Because how the proxies work is they add an additional root key into the (victim) browser during some form of configuration.   DANE makes the injected root key no longer valid.

Of course, certificate pinning and other techniques has the same problem, and IMO, killing the idea of TLS proxies is a feature, so DANE's general incompatibility with TLS proxies is a feature, not a bug.

---

From: Lutz Donnerhacke <[email-masked]>
Date: Fri, 12 Oct 2012 11:00:39 +0200

> Why are proxies a problem for DANE in particular, rather than TLS in

TLS man in the middle proxies are easy to implement with faking
certificates (on the fly for local enterprise CA or by obtaining fake certs
from well known CAs).

With DANE, there is a problem: You need to modify the DNSSEC chain on the
fly.

So what Marc is asking for is a way to forge DNSSEC answers for legal and
illegal purposes, cooperate and secret services. It's sufficent to provide
such a system for DANE only.

The most obvious solution is to install mandantory DLV in the resolvers, so
urging such support for DANE applications.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 12 Oct 2012 11:24:52 +0200

Hi Marc

I assume you're talking about TLS proxies rather than HTTP proxies. Those are in a position to sign certificates on behalf of al the https servers in the world, that would be trusted by the client. If they have that kind of control, I don't see how they'd have any problem either filtering out TLSA records from DNS queries and responses or getting the client to trust their own signatures.

A draft from a few months ago ( http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 ) would solve this problem, as it allows the client to see the real certificate. But that TLS extension was rejected, so it's pretty much dead.

Yoav

On Oct 12, 2012, at 9:28 AM, Marc Lampo wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 
> Scanned by Check Point Total Security Gateway.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 12 Oct 2012 11:37:17 +0200

> apply/work even in the presence of proxies.

There are no proxies defined for TLS at least in the IETF context. TLS
is an end-to-end protocol. What you call a proxy is performing a
man-in-the-middle attack on the protocol. It succeeds by inserting a
"proxy" certificate in the user's trusted CA list. In that context it
is good that DANE detects those attacks.

I suppose that such "proxies" would just insert their key as a DNSSEC root key.

regards,
Nikos

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 12 Oct 2012 11:37:36 +0200

Hi Yoav,

About: DNSSEC can detect filtered out information (often not
understood as it involves that complicated denial of existance part of
DNSSEC).

On 10/12/2012 11:24 AM, Yoav Nir wrote:
> Hi Marc
> 
> I assume you're talking about TLS proxies rather than HTTP
> proxies. Those are in a position to sign certificates on behalf of
> al the https servers in the world, that would be trusted by the
> client. If they have that kind of control, I don't see how they'd
> have any problem either filtering out TLSA records from DNS queries
> and responses or getting the client to trust their own signatures.

A resolver can detect that TLSA records have been filtered out.  (but
cannot then reconstruct that data, i.e. no connection).

> A draft from a few months ago ( 
> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 )
> would solve this problem, as it allows the client to see the real 
> certificate. But that TLS extension was rejected, so it's pretty
> much dead.

Well, would not see the real certificate, but know that trouble exists
(TLSA got filtered) and can stop the connection.

Technically, the resolver knows that 'it could not successfully prove
that the TLSA did not exist', and it cannot get a TLSA.  So, the
fallback to plain PKIX should not be performed.

Best regards,
   Wouter

---

From: Tom Ritter <[email-masked]>
Date: Fri, 12 Oct 2012 08:00:40 -0400

If the DNSSEC verifier (or whatever the correct term is) is inside the
application doing TLS - it isn't a problem.  (This *should* cover
browsers, when they get around to implementing DANE.)  It will
probably be handled in the same way Certificate Pinning is handled.
If a certificate is signed by a Root CA that is installed locally into
the trust store - Certificate Pinning does not apply.  Likewise, DANE
would (probably) not apply.

For any application that does not have a local trust store to install
root certificates in or does not perform it's own DNSSEC validation -
proxies would indeed break DANE.  And as mentioned, I think that is a
feature, not a problem.  If the application was willing to be proxied,
it would support those features as hook points to manipulation trust
validation.

-tom

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Oct 2012 13:23:08 -0400 (EDT)

> Before the draft was adopted as RFC I asked how to cope with proxies.

And we had the same discussion we are having now.

> reading this, I assume) to simply state to get rid of them !

I clearly stated when when making remark that it was my _person_ view,
with no hats on. I personally believe MITM proxies are bad for security. I
understand that there is a need for them both in the enterprise and at
the dictatorship levels, neither of which affect me personally.

> apply/work even in the presence of proxies.

Please go re-read RFC 1984.

If you are legitimately needing to dictate local policy to ignore TLSA
records, ask your vendor (browser, OS, etc) for support in enforcing
such an override on the application/OS level.

It cannot ever be part of the protocol level.

> internal hosts don't need access to public IP addresses

As I explained during that talk, but perhaps not clearly enough, is
that you have the option of using a SOCKS proxy, in which case DNS lookups
should done by your SOCKS proxy server, and any DNS and DANE processing would be
done there.

I would assume any browser supporting SOCKS would disable TLSA checking
when SOCKS is enabled. If not, file a bug with the vendor.

i.e. see: http://kb.mozillazine.org/Network.proxy.socks_remote_dns

> However, TLSA is not "an address", so access to public DNS is needed.

No, when configured using SOCKS, you should not need to do DNS
yourself. You just get your TCP streams.

> servers, only few users actually benefit, at this moment.

Give it another year or so and you'll see the proliferation of
validating resolvers on lots of end nodes.

> users are not capable of noticing this anyway.

"most users" would dramatically change if say firefox, chrome or android
would start validating DNSSEC. And that's really a matter of "when", not
"if".

Paul

---

From: [email-masked] (Martin Rex)
Date: Sat, 13 Oct 2012 01:39:09 +0200 (CEST)

> However, TLSA is not "an address", so access to public DNS is needed.

"Proxy" is a very generic term and means different things to different
people.  What would need to have extended is the information exchange
between the TLS client and the proxy when performing the proxy traversal.

A solution for client-side HTTP Proxies that support the "HTTP CONNECT"
method would be to have the Proxy perform the TLSA lookups just the way
that it performs the DNS lookup for the target hostnames, and return
all relevant raw DNS records base64-encoded in header fields of the proxy
response to the HTTP CONNECT method.

-Martin

---

From: Danny McPherson <[email-masked]>
Date: Sun, 14 Oct 2012 21:47:55 -0400

> Of course, certificate pinning and other techniques has the same problem, and IMO, killing the idea of TLS proxies is a feature, so DANE's general incompatibility with TLS proxies is a feature, not…

Not to pile on, but I concur; definitely feature; in both the context of pinning and proxies.  

-danny