Subject: [websec] DNS publication of HSTS and PKP header data using CAA

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 18:00:27 -0400

http://tools.ietf.org/html/draft-hallambaker-webseccaa-00

It is a pretty straightforward proposal:

* Use the CAA record with either the hsts or hpkp tag
* Put the same text you would have put into the CAA record value field

There are a few differences in interpretation. All we are trying to do
here is to help people to close the 'secure after first use' hole, not
replace.

Given that we have quite a bit of use of HSTS headers, providing a
mechanism for publishing this in the DNS looks like being the obvious
approach.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 8 Apr 2015 18:18:56 -0400

> mechanism for publishing this in the DNS looks like being the obvious

A quick question....

> * Put the same text you would have put into the CAA record value field

This is obviously predicated on an online app and DNS. Is there any
interest in Installable Web Apps delivered over a trusted distribution
channel?

Installable Web Apps are simply web apps with a manifest that are
packaged and installed like more traditional apps. They still use the
same technologies, like HTML, CSS and JavaScript. The trusted
distribution channel ensures the app is not tampered during delivery.
The class of app is supported by both Firefox and Chrome.

In the case of installable apps, the information like HSTS and HPKP
can be placed in the app manifest. Even better, standards like HPKP
won't need to provide the override because its confused about which
pinset is the right one to use. Because the HSTS and HPKP information
was in the manifest during delivery, there will be no question about
which policy or key to use.

Jeff

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 8 Apr 2015 15:35:10 -0700

>  mechanism for publishing this in the DNS looks like being the obvious

I believe it was so obvious that the IETF has already beat you to the
punch - RFC 6698.

If it is, as you claim, to close the "secure after first use" hole - which
is the first time I've heard it called that, versus the "trust on first
use hole", since "secure after first use" isn't so much a "hole" as a
"nice thing to have" - then it requires secure DNS, which is back to the
DNSSEC problem, and if you have DNSSEC and the ability to query arbitrary
records on the client, well, you might as well just use DANE.

Of course, you might mean this as a "How do I discover support" (e.g. for
building preloaded lists), in which case, that problem already has a
myriad of solutions.

In either event, I see no reason to standardize Yet Another Way to do the
same thing.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 8 Apr 2015 15:38:58 -0700

>  interest in Installable Web Apps delivered over a trusted distribution

That's a question for the W3C, not the IETF.

>  The class of app is supported by both Firefox and Chrome.

The summary doesn't match what is supported, but that's a question for the
W3C.

>  which policy or key to use.

By "the override", I presume you mean "the ability for a duly authorized
user with administrative access over the machine they own to set policies
for the applications they install", which you've objected to in the past,
in which case, there's no reason at all to assume that the respect for a
user's wishes over that of the developer's would somehow be inverted.

The W3C is quite nice in spelling this out -
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

In either event, it sounds very much like a question for the W3C and the
format application manifests take and are extended, and nothing to do with
this WG.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 8 Apr 2015 18:48:13 -0400

> user's wishes over that of the developer's would somehow be inverted.

How did I know you would object to an effective security measure that
minimized the ability to intercept communications :)

I'd also cite the same document and claim that when the user installed
the application with the preloaded and *known secure* settings, they
would not want them arbitrarily overridden because a standard was
confused about which pinset was the right one to use. As you
succinctly said, its a Priorities of Constituencies.

Jeff

---

From: Joseph Bonneau <[email-masked]>
Date: Wed, 8 Apr 2015 16:38:25 -0700

On Wed, Apr 8, 2015 at 3:35 PM, Ryan Sleevi <[email-masked]> wrote:
>>  It is a pretty straightforward proposal.

> In either event, I see no reason to standardize Yet Another Way to do the

I do. Not all Ways to Do The Same Thing are equal in practice, even if
they're equal in theory.

DANE is complicated and has a completely different syntax. It is a 37
page long. Philip's proposal is 6 pages long. There is probably more
to be added but that is still telling. If a busy site admin asks "how
can I close the trust-on-first-use hole for my site?" Would we rather
reply with:

1) Copy your HSTS and HPKP headers into a DNS record

or

2) Go read up on how DANE works, come up with a DANE policy that's
compatible with your HSTS/HPKP preferences (which may not be precisely
possible), and keep the two policies compatible as they evolve.

Perhaps DANE offers sufficiently extra expressive power for some
super-energetic admins will prefer approach 2, but I think 9 of 10
developers (at least) would rather only have to learn and manage one
syntax.

My recent research on HSTS and HPKP deployment in practice has
convinced me that much more attention needs to be paid to making
developer's lives easier.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 19:40:35 -0400

> records on the client, well, you might as well just use DANE.

Who said anything about DNSSEC being required?

DANE has totally different syntax and semantics. Adding this mechanism
is very straightforward, just post the same parameters that would be
presented in the HTTP headers in DNS. The mechanism can even work both
ways, a server can use this for discovery.

People in WebSec and DANE decided on different approaches. I see no
reason to foist the inability of the two groups to agree on one
approach onto users of the specs and certainly no reason to hobble
WebSec which is now widely used to make space for an experimental
protocol that has failed.

> building preloaded lists), in which case, that problem already has a

Having more than one solution for a problem is usually a good reason
to pick one.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 9 Apr 2015 09:00:05 +0900

> It is a pretty straightforward proposal:

I haven't gotten further than the title. That indeed looks extremely 
straightforward, but probably a bit too simple :-).

It's just "Title".

Regards,   Martin.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 8 Apr 2015 17:41:19 -0700

>  Who said anything about DNSSEC being required?

If it isn't, then it's not equivalent.

HSTS requires an error free connection - in part to ensure the policy is
securely delivered.

HPKP requires an error free connection that is consistent with the policy
expressed - in part to ensure the policy is securely delivered and
correctly formed.

If you don't require secure delivery of that, then you're not developing a
secure solution.

If you're doing it for out of band discovery, then it would help to say
that. But I very much doubt you are.

>  Having more than one solution for a problem is usually a good reason

http://xkcd.com/927/

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 8 Apr 2015 17:48:28 -0700

>  developer's lives easier.

I certainly agree with this.

>From a UA perspective, does this address any of the concerns that
DANE/DNSSEC suffer from? No, not really.

So is this an improvement over DANE/DNSSEC? Only in syntax, not in
deployability.

Respectfully, this is a solution in search of a problem space. That
Phillip suggests it's deployable without DNSSEC is itself telling that
it's not meant to be an apples:apples conversion for the client. If we
assume it's for discoverability for reploads, then it's ill-defined who
the discovering actors are and whether or not they're interested in it,
but is a question worth having in the "Is this a problem" side before a "I
have a solution" side is broached.

When I look at this from the "What problem does it solve" and "In doing
so, does it introduce new problems" perspective, I'm not sure I agree with
the first question, and even if I did, the answers to the second question
are rightfully concerning.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 20:57:57 -0400

> straightforward, but probably a bit too simple :-).

Yeah, its a bug in a new feature I added into my word->RFC processor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 21:27:22 -0400

> HSTS requires an error free connection - in part to ensure the policy is

No it is required to know that the policy is consistent. Which you
certainly want to do if a security policy is going to be cached for 6
months.

The security considerations of security policy mechanisms are all
about not shooting yourself in the foot. That is why I propose to not
consider the record valid for any longer than its DNS time to live.

> If you don't require secure delivery of that, then you're not developing a

I am not delivering a perfectly secure solution but neither is DANE.
All I am looking to do is to improve on the status quo with as little
extra work as possible.

If DNSSEC is ever deployed AND it becomes visible to clients then it
could be relevant to this spec. But right now DNSSEC is not a viable
mechanism for authenticating DNS RRs at the client. There are other
mechanisms that work just fine for the client-resolver link, including
our own proprietary protocols and the proposal we have made to DPRIV.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 8 Apr 2015 18:52:04 -0700

On Wed, April 8, 2015 6:27 pm, Phillip Hallam-Baker wrote:
>  about not shooting yourself in the foot.

No, they aren't. They're also about mitigating the worst that an
"attacker" could do.

>  That is why I propose to not consider the record valid for any longer
than its DNS time to live.

And now your TTL and the client caching policy of that TTL becomes part of
your security considerations.

>  All I am looking to do is to improve on the status quo with as little

All I see are negatives here compared with "the status quo".

>  mechanism for authenticating DNS RRs at the client.

Agreed. And so how are you going to bootstrap security over an insecure
connection, without dealing with all of the threat scenarios explicitly
and implicitly addressed by the documents you're trying to
supplant/augment?

I would encourage you to consider the exercise of "What is the worst that
an attacker could do with this policy", as well as "What's the strongest
level of security I could achieve", and hopefully in both cases you'll see
that the flaws are somewhat fundamental if delivered over an insecure
transport. And if you had a secure transport (which you don't, but we'll
assume the IETF will fix all this in good time), then you *could* use
DANE, and the only issue becomes one of syntax. Which is not an
intrinsicly good argument - and in fact, generally a bad one (syntax can
be hidden by tools, but specs - and bad specs - live forever)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Apr 2015 22:37:00 -0400

> and implicitly addressed by the documents you're trying to

We are agreed that the utility of DNSSEC is limited to authoritative
name resolvers, if that.

So rather than trying to build further on a dead end, I propose to
work in the opposite direction. We have a deployed scheme that already
works inband in HTTP, extending it to DNS publication is the logical
next step to extend the scheme further. Once that is in place there is
an incentive to deal with authenticating the DNS client-resolver
connection.

We can argue about the security benefits achieved through this
particular proposal, but what do you expect from two pages?

What I propose is that we take the low hanging fruit now and let folk
who have complicated boil the ocean approaches continue to fend for
themselves.

---

From: [email-masked]
Date: Tue, 14 Apr 2015 10:44:15 -0500

I support Hallam-Baker views on this.
Regards,
/Janvier Ngnoulaye

Le Mer 8 avril 2015 21:37, Phillip Hallam-Baker a écrit :
>>  connection, without dealing with all of the threat scenarios
>> explicitly and implicitly addressed by the documents you're trying to
>> supplant/augment?
>
> works inband in HTTP, extending it to DNS publication is the logical next
> step to extend the scheme further. Once that is in place there is an
> incentive to deal with authenticating the DNS client-resolver connection.
>
> _______________________________________________
> websec mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 27 Apr 2015 07:13:18 -0400

> mechanism for publishing this in the DNS looks like being the obvious
Off topic, but related: "Please add Pinning Pinsets and CSP to App
Manifest," https://bugzilla.mozilla.org/show_bug.cgi?id=1158756.

The more channels this information is available the better. Choice is
always good. And context specific security information is even better.