[websec] Comments on "I am testing HSTS"-directive and Issue #41 add parameter "hardfail=no"?

[Tobias Gondrom <[e-mail]>]

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:
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec