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

["Ryan Sleevi" <[e-mail]>]

On Wed, April 8, 2015 6:27 pm, Phillip Hallam-Baker wrote:
>  The security considerations of security policy mechanisms are all
>  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.

>  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.

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

>
>  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.

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)