Re: fyi: Strict Transport Security specification

On Mon, Sep 21, 2009 at 11:51 AM, Adam Barth <w3c@adambarth.com> wrote:
> Folks debugging their own site have lots of tools to figure out what's
> going on.  I'd probably recommend a tool like Fiddler2, which gives
> much more technical details than a browser UI.  If an end user want to
> get around the error, they can clear the STS state in much the same
> way they can manage cookies.  The main consideration is not to have a
> UI flow from the error page to the "ignore this error" action.

Agreed.

> There are lots of ways of extending the header to address more use
> cases.  For version 1, I think we should focus on addressing the core
> use case of a high-security site trying to protect its Secure cookies
> from active network attacks.  That being said, I think we should
> define the grammar of the header in such a way (i.e., tolerant of
> additional tokens) that we can add more features in the future.

Yes, that sounds like a good plan.

> I agree that once DNSSEC is the deployed, it will be a good way to
> deliver an STS policy.  There's actually a proposal floating around to
> do exactly that, but I can't put my fingers on it at the moment.  In
> any case, I don't think we want to wait for DNSSEC before deploying
> this feature.

No, definitely not.

> Imagine a deployment scenario like https://www.stanford.edu/ where
> students can host PHP files in their user directories.

Ah, so this is exactly what you were discussing with Jonas.  That
makes sense, yes.  Such a site would be very insecure anyway, of
course -- any student could read any other student's app's cookies.
But I understand the concern, anyway.

Received on Monday, 21 September 2009 16:14:41 UTC