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