Re: [websec] Issue #41 add parameter indicating whether to hardfail or not

[Eric Rescorla <[e-mail]>]

On Fri, Jun 29, 2012 at 8:10 AM, Steingruebl, Andy
<[e-mail]> wrote:
>> The point of "this is testing" is  the opposite: people who can't talk to you because you've configured HSTS in a way inconsistent with your
>> actual site posture.
>> -Ekr
>
> Can you give us an example of how/where you think this could occur and how it is distinct from other ways you could using existing technology kill your site?
>
> As an admittedly snarky example you could easily public a bad A record in DNS and you'd never see any traffic at all, but there isn't a "test new A record flag" or "test new MX server" flag in the DNS.
>
> We assume that as part of deploying HSTS people do some basic checks like make sure their website actually responds over HTTPS and generates webserver logs, and they know which domain they are publishing HSTS records for.
>
> Some specifics would help me a lot to understand the concerns.

The primary concern is that HSTS is intended to have a very long
lifetime and that
is a security tradeoff, not just an operational cost tradeoff like DNS TTL.

It's not so much with existing HSTS as with something like
draft-evans-palmer-hsts-pinning.
Consider the case where I operate a site that load balances between
two certs, A and B
but I inadvertantly advertise a pin for A only. If I understand S 2.1
correctly, any
client who goes to A will get pinned and any client who goes to B will
reject the
pin (regardless of whether it's served.) If the client comes back and gets B
later, they will reject the cert.

This is not easy to detect with the kind of testing you describe.

-Ekr