Re: VeriSign feedback/comments on STS -06

2010/5/17 Henrik Nordström <henrik@henriknordstrom.net>:
> What I do not get is why this is addressed at the HTTP level. My first
> reaction is that this belongs at either the SSL or DNS layers, not HTTP.

Is there any specific disadvantage to having it at the HTTP level?
The goal as it stands is HTTP-specific: all HTTP traffic should be
encrypted.  If you put the declaration anywhere other than HTTP, that
opens the question of what other protocols it should apply to, if any.
 If there is a need for a flag like this in non-HTTP contexts, I'd
think site operators would want to enable it separately for separate
protocols -- e.g., they might offer HTTPS but only offer unencrypted
SMTP.

> SSL by atting a suitable attribute to certificate.

Wouldn't this require that you get a new certificate from your CA if
you want to change your policy on STS (even, e.g., changing the
expiration)?  I assume this would inevitably be nontrivial.  Also,
wouldn't CAs have to support it, instead of just browsers?  HTTP
headers can be added with no support by anything other than web
browsers.  (I don't know much about certificates, so maybe I'm
off-base here.)

> DNS by adding a DNS record stating the site policy, similar to as has
> been done for SMTP and other protocols for similar policy purposes. This
> way it's possible to prevent user agents from even trying to access the
> site using http, automatically swithing to https even if the user did
> not ask for it. Sure, DNS isn't at it best days with cache poisoning
> attacks, but that's improving considerably thanks to "new"
> recommendations and with DNSSec becoming common in the not too distant
> horizon it should relatively soon be very much on track again.

Sending an HTTP header works right now, which is a big advantage.

Received on Monday, 17 May 2010 21:34:30 UTC