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

From: =JeffH <[email-masked]>
Date: Tue, 12 Jun 2012 00:00:43 -0700

Hi, thanks for your thoughts Yoav, apologies for latency,

 > I guess my issue with this..

..where "this" is denying the user the capability to "click-through" TLS/SSL 
errors/warnings in all error cases..

 > ..is because when I read the draft for the first
 > time, I thought this would be a good idea for websites that only do HTTPS and
 > do not do HTTP except to redirect to HTTPS. I thought it would allow them to
 > signal this information, and allow them to defeat HTTP-based MiTM attacks.

Yes, that is exactly the benefit the spec provides.

 > The
 > draft as it stands is not a good fit for this use case, because it requires
 > more of the administrator than is currently reasonable to expect.

If an admin is uncertain about their keeping their TLS/SSL certificate 
deployment up-to-date, then they shouldn't declare themselves as an HSTS Host.

And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded list, 
nor the upcoming Firefox one.

 > I could propose an "HSTS-light" header for this use case, but I don't think
 > anybody would like to have that.

Yeah, I'm not sure that's necessary, because what we're talking about here 
really is whether the user is offered obvious recourse to proceed with loading 
the web app in the face of TLS/SSL errors -- i.e., to be allowed to "click 
through" -- and in most (all?) browsers, the user is allowed to recourse to 
click through many TLS/SSL errors. So in some sense it is the status quo for a 
plain old non-HSTS web app.

In the Paris WG session, the discussion of the above morphed to thinking about 
having a new "this site is testing HSTS" directive.

In thinking about this, we don't think it is really necessary because if one 
declares one's web app as being HSTS, one can watch server logs to see if any 
requests come in over plain http, and then go track those issues down. You 
don't really need the user agent's help to figure out what is happening. It's 
just going to mechanically transform all http URIs pointing to your site into 
https ones, and try to load them, and if they 404, you'll know it (via your logs).

It's arguably different with Content Security Policy (CSP) -- which is where 
the discussed notion came from ("report-only") -- because in CSP, the user 
agent is enforcing policy on loaded content within itself and there may be no 
other way to figure out what it's doing.

HTH,

=JeffH

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 18 Jun 2012 19:01:30 +0100

Hello all,

<hat="WG chair">

I would like to ask for feedback/opinions from the WG on this draft 
regarding the following open issue:

- in Paris we had a discussion about whether HSTS header should specify 
a "I am testing HSTS" directive. There was some support for this in the 
room but no consensus.
I would like to make a final invitation for comments/views/opinions on this?

- And as this is somehow related:
the still open #41: should HSTS have an option like "hardfail=no"?
Our meeting discussion in Paris did not show consensus in support of this.

and just in case anyone wants to read up on our meeting minutes from Paris:
http://www.ietf.org/proceedings/83/minutes/minutes-83-websec.txt

Best regards, Tobias

</hat>

On 12/06/12 08:00, =JeffH wrote:
> ..where "this" is denying the user the capability to "click-through" 
> TLS/SSL errors/warnings in all error cases..
>
> And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded 
> list, nor the upcoming Firefox one.
>
>
> Yeah, I'm not sure that's necessary, because what we're talking about 
> here really is whether the user is offered obvious recourse to proceed 
> with loading the web app in the face of TLS/SSL errors -- i.e., to be 
> allowed to "click through" -- and in most (all?) browsers, the user is 
> allowed to recourse to click through many TLS/SSL errors. So in some 
> sense it is the status quo for a plain old non-HSTS web app.
>
>
> In the Paris WG session, the discussion of the above morphed to 
> thinking about having a new "this site is testing HSTS" directive.
>
> In thinking about this, we don't think it is really necessary because 
> if one declares one's web app as being HSTS, one can watch server logs 
> to see if any requests come in over plain http, and then go track 
> those issues down. You don't really need the user agent's help to 
> figure out what is happening. It's just going to mechanically 
> transform all http URIs pointing to your site into https ones, and try 
> to load them, and if they 404, you'll know it (via your logs).
>
> It's arguably different with Content Security Policy (CSP) -- which is 
> where the discussed notion came from ("report-only") -- because in 
> CSP, the user agent is enforcing policy on loaded content within 
> itself and there may be no other way to figure out what it's doing.
>
> HTH,
>
> =JeffH
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Jun 2012 13:20:12 +0100

Hi Jeff,
Sorry for even slower response.

On 12/06/2012 08:00, =JeffH wrote:
  [...]
> to load them, and if they 404, you'll know it (via your logs).
(Speaking as a WG participant, not as a co-chair.)

I don't think relying just on server side logs is actually a good idea. 
You are effectively limiting who is able to debug the problem, which 
sometimes can be caused by things outside of direct webserver 
administrator control. Existence of "I am testing HSTS" directive would 
allow browsers to present debug information on HSTS succeeding/failing 
in some form (browser logs, additional debug frame, etc.)

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 07:29:28 -0700

On Tue, Jun 12, 2012 at 12:00 AM, =JeffH <[email-masked]> wrote:
> really is whether the user is offered obvious recourse to proceed with
> loading the web app in the face of TLS/SSL errors -- i.e., to be allowed to
> "click through" -- and in most (all?) browsers, the user is allowed to
> recourse to click through many TLS/SSL errors. So in some sense it is the
> status quo for a plain old non-HSTS web app.
>
>
> In the Paris WG session, the discussion of the above morphed to thinking
> about having a new "this site is testing HSTS" directive.
>
> declares one's web app as being HSTS, one can watch server logs to see if
> any requests come in over plain http, and then go track those issues down.

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

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Fri, 29 Jun 2012 15:10:42 +0000

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

- Andy

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Jun 2012 17:24:54 +0100

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

Maybe this is not a good example, but I am thinking that something like 
OCSP retrieval failing on the client side is not something that would 
show up in the webserver logs.

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

There is however "I am testing DKIM" flag published in DNS.

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Fri, 29 Jun 2012 16:45:00 +0000

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> 

Sure, but doesn't the OCSP site know whether it has set HSTS?

> There is however "I am testing DKIM" flag published in DNS.

Yep, but here you may not know all your sources of email, all of the domains, senders, etc.   you could have an outsourcer sending mail on your behalf that you don't know about, haven't inventoried, etc.  

For HSTS that can't be the case.  For HSTS you do know exactly what domain/host you're applying HSTS to.  You don't necessarily know all of the inbound links, but you don't know that before HSTS an so you watch your weblogs for 404's for example to see typo'd links, inbound errors, etc.

My contention is we already have this problem solved, and don't need a testing mode for it like this as there aren't any cases where the browser won't at least try to connect, and you can have an endpoint there ready/willing/able to listen to the request that is made.  If nothing else you could put up a packet sniffer.

- Andy

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2012 11:13:03 -0700

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Jun 2012 19:37:39 +0100

> Sure, but doesn't the OCSP site know whether it has set HSTS?
You might be thinking of a different usage of OCSP.

I was thinking about: a browsers gets certificate from TLS. It tries to 
verify it using OCSP against a third party OCSP server. The OCSP server 
is down. Now the website the browser is trying to access is effectively 
down with HSTS enabled.

---

From: Adam Barth <[email-masked]>
Date: Fri, 29 Jun 2012 13:10:16 -0700

On Fri, Jun 29, 2012 at 11:37 AM, Alexey Melnikov
<[email-masked]> wrote:
> verify it using OCSP against a third party OCSP server. The OCSP server is
> down. Now the website the browser is trying to access is effectively down
> with HSTS enabled.

Right, this is why browsers don't use OCSP.  The problem here is OCSP, not HSTS.

Adam