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

From: "Ryan Sleevi" <[email-masked]>
Date: Sun, 14 Oct 2012 20:13:23 -0700

On Fri, October 12, 2012 1:57 am, Nicholas Weaver wrote:
>
>  On Oct 12, 2012, at 9:45 AM, Tony Finch wrote:
>
> > Marc Lampo <[email-masked]> wrote:
> >
> >> 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?
>
>  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.

Public Key Pinning, as implemented in Chromium, only evaluates pins
against publicly trusted root certificates (that is, roots which
participate in the various platforms' root certificate programs).

When the certificate chain that was validated in the client does not
terminate in a "publicy trusted" anchor, pinning is not enforced. If you
have sufficient privileges to install a local trust anchor on a users
machine - whether by means technical or policy - then such local settings
are respected by Chromium.

For users who are not operating in such scenarios, public key pinning
offers a robust defense against future Diginotar-like misissuance. For
users who do operate in such environments, it is presumed (albeit
unlikely) that the (enterprise) endpoint terminating the TLS connection is
performing these checks. In the reality that many such solutions are not,
proposals such as
http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 or
http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00 would allow
clients to implement such security policies.

Such scenarios are not strictly relegated to "enterprise" scenarios, where
there are effectively three parties participating in the end-to-end
session (user, enterprise, site). It's unfortunately common that a number
of antivirus vendors have begun shipping local "TLS proxies" as part of
their traffic inspection anti-virus/user-protection platforms. These are
solutions that the user directly opts in to (by choice of installing the
antivirus and configuring it to do so). Thus, I'm not sure that RFC 1984
really comes into play here - this is the user wanting to configure a
local policy that can be respected regardless of the applications running
on their machine.

For DANE, presumably solutions would use some form of DNSSEC rewriting,
with DLV, to accomplish the equivalent. That, or individual applications
would have explicit options to configure such scenarios. Of course,
without some form of central trust mechanism - as exists on Windows and OS
X, and as does not exist on most Linux-based distros - it's likely that
many applications will end up trying to roll their own settings, and
getting them wrong or being otherwise unmaintainable at scale. The same as
it is today with application support for explicit (not TLS) proxies such
as SOCKS or HTTP.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Oct 2012 11:56:56 -0400 (EDT)

On Sun, 14 Oct 2012, Ryan Sleevi wrote:

> with DLV

That's not the purpose of DLV. DLV is going to die sooner rather then later,
and no infrastructure should be build up to use it for such purpose.

I hope the operator of the DLV registry will confirm this in strong terms.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Oct 2012 10:48:02 -0400

I think that is a rather naive assessment.

Most of us do not want to be dependent on a single root of trust that is
ultimately under the physical control of VeriSign and the legal control of
ICANN, a body whose insistence that it is above criticism should be deeply
troubling. Attempts to concentrate trust in one place have invariably
proved to be unstable.

DLV is not the solution but it may be a useful contribution to a solution.

On Mon, Oct 15, 2012 at 11:56 AM, Paul Wouters <[email-masked]> wrote:

> ______________________________**_________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dane<https://www.ietf.org/mailman/listinfo/dane>
>

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Oct 2012 11:11:45 -0400 (EDT)

On Tue, 16 Oct 2012, Phillip Hallam-Baker wrote:

> Most of us do not want to be dependent on a single root of trust that is ultimately under the physical control of VeriSign and the legal
> control of ICANN, a body whose insistence that it is above criticism should be deeply troubling. Attempts to concentrate trust in one place
> have invariably proved to be unstable.
> 

You are confusing the DLV method with the dlv.isc.org instance.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Oct 2012 20:28:56 -0400

I don't understand why you would think that.

Handing control of the Internet to Paul V. is obviously not a solution to
the concentration of trust issue. The problem is not who is in control but
the monopoly of control.

A system of multiple DLV registries with different signing keys would be
much better. Especially if zones were signed by multiple registries.

On Tue, Oct 16, 2012 at 11:11 AM, Paul Wouters <[email-masked]> wrote:

>> ultimately under the physical control of VeriSign and the legal
>> control of ICANN, a body whose insistence that it is above criticism
>> should be deeply troubling. Attempts to concentrate trust in one place

---

From: Ben Laurie <[email-masked]>
Date: Fri, 19 Oct 2012 14:54:25 +0100

On 16 October 2012 15:48, Phillip Hallam-Baker <[email-masked]> wrote:
> troubling. Attempts to concentrate trust in one place have invariably proved
> to be unstable.
>

How about a solution that doesn't require you to trust anyone - namely
Certificate Transparency?

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Oct 2012 10:07:22 -0400

> Certificate Transparency?

Let's not be hyperbolic here.  You still have to trust the whitelist/log operator, since he can DoS by not including certificates in his log.

But this is drifting pretty far off-topic...

--Richard

---

From: Ben Laurie <[email-masked]>
Date: Fri, 19 Oct 2012 15:22:54 +0100

> Let's not be hyperbolic here.  You still have to trust the whitelist/log operator, since he can DoS by not including certificates in his log.

I guess it would not be hard to prove that the log is doing that - the
whole point of CT being that misbehaviour can always be demonstrated.

> But this is drifting pretty far off-topic...

Well, DANE is about improving TLS, and so is CT :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Oct 2012 10:42:50 -0400

On Fri, Oct 19, 2012 at 9:54 AM, Ben Laurie <[email-masked]> wrote:

> proved

I would not go that far for CT.

I think Transparency is the most important new idea in security for quite a
while. But Transparency does not remove the need to trust the certificate
issuer to do the job right. It merely creates a more effective feedback
loop.

While there is not a lot of difference in terms of the strength of the
trust provided, the consequences for the cost of providing that cost are
significant. CT does not eliminate the need for CAs to run their facilities
correctly and validate cert requests effectively. All CT does is to create
a new stick to beat the ones that don't.

Now if you had actually created a mechanism that did not require trust at
all and it was possible to administer it in a practical way (contra
Sovereign Keys) then you could eliminate those costs.

Now there might be a way to graft CT onto DNSSEC via DLV and maybe we
should look at that as well. There is a big policy level incentive to do
that as the mono-root structure is far too much of a liability right now. I
don't think any of us would be at all comfortable with ITU running that
root. And the SCO faction are certainly not going to accept ICANN running
that root. So what we are headed for right now is a fracture of the root.

At present I think we should concentrate on CT for PKIX. But if things spin
out of control in Dubai we might well find  that this is a much more urgent
question. Though not one that is likely to be viable in IETF given the
popularity of my IPv6 Sovereign Allocation proposal here.