Re: [websec] #7: clarify and add examples/justification wrt connection termination due to tls warnings/errors

["websec issue tracker" <[e-mail]>]

#7: clarify and add examples/justification wrt connection termination due to
tls warnings/errors


Comment(by jeff.hodges@…):

 see also....

 http://www.ietf.org/mail-archive/web/websec/current/msg00063.html

 Subject: Re: [websec] Some questions about HSTS
 From: Adam Barth <[e-mail]>
 Date: Mon, 22 Nov 2010 22:06:24 -0800
 To: Yoav Nir <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>

         (text/plain)
 On Mon, Nov 22, 2010 at 9:46 PM, Yoav Nir <[e-mail]> wrote:
 > Taking both your answers together, suppose I have a web server with a
 corporate or self-signed certificate, which is OK, as I expect all my
 users to approve an exception (as it's called in Firefox). I turn on HSTS
 because I'm worried about them being duped by a fake server using HTTP. To
 me, HSTS reduces the attack surface by making them dupable only on the
 first ever connect. Then, as it turns out, a certain browser breaks the
 connection when connecting from outside the organization, because the CDP
 is not available. Fine, I turn off HSTS, but because the cache is
 untouched, the users will get intermittent connectivity problems for three
 more months.

 I don't recommend using HSTS with self-signed certificates.  In this
 scenario, I'd recommend the corporation install a root certificate in
 all machines owned by the corporation and then use that root
 certificate to issue whatever other certificates the corporation
 needs.

 > I agree with Marsh, that this is too much of scope creep. It makes sense
 for a big website like paypal, amazon or gmail to want strict enforcement
 on the client. But smaller websites don't have the IT department of such
 companies, and often let their certificates expire. In their case, having
 HSTS on would cause a lot of trouble on certificate expiry day.

 Folks are already in for a headache if they let their certificates
 expire.  They'll get big nasty warnings in either case.  The
 difference is only whether those warnings will let the user ignore
 them.

 If you don't think your organization is sufficiently competent to
 schedule a reminder to update its certificates, then I don't recommend
 using HSTS.

 > The use case that I am interested in is not a big commercial website,
 but rather an SSL-VPN portal. These have two relevant properties: They
 come pre-packaged, and they're SSL-only. It is up to the customer to get a
 certificate, or generate a self-signed one. I would have liked to have
 HSTS on by default for such a product, but if that means that customers
 with self-signed certificates or corporate certificates get long-lasting
 connectivity problems, I can't justify that.

 Indeed.  Please don't use HSTS with self-signed certificates.  HSTS is
 a feature for well-maintained web sites that have a need for strong
 security.  The reason we designed HSTS was to differentiate between
 sites that actually want strong security and sites that are using TLS
 but don't have strong security needs.  If you don't need strong
 security, you don't need HSTS (and the additional careful
 administration it requires).

 > Sure, I can have a configuration flag for whether or not we should have
 the header, but administrators tend to configure those wrong just as much
 as users tend to click through dangerous screens.

 I don't think user agents should offer such a configuration flag.

 > What do the current implementations (Chrome, Firefox) do?

 They do what the spec says.  TLS errors on HSTS hosts are treated as
 fatal errors, much like the host's DNS name not resolving.  There is
 no recourse except to reload the page.

 Adam



 ###

 http://www.ietf.org/mail-archive/web/websec/current/msg00304.html

 Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
 From: Adam Barth <[e-mail]>
 Date: Tue, 29 Mar 2011 13:58:08 -0700
 To: [e-mail]

         (text/plain)
 There's no coupling between HSTS and the particular algorithm a UA
 uses to verify certificates.  The UA is free to use whatever
 verification mechanism it desires.  You can remove whatever CAs you
 consider sloppy from the list of trusted certificate authorities and
 add in whatever other verification mechanism you like.

 For example, if/when certificate verification through DNSSEC becomes
 widespread, we won't need to change anything about the HSTS spec.  Of
 course, we'll need to change our implementations, but that's true
 regardless of what the HSTS spec says.

 Adam

-- 
-------------------------------------------+--------------------------------
 Reporter:  jeff.hodges@…                  |       Owner:  =JeffH
     Type:  defect                         |      Status:  new   
 Priority:  major                          |   Milestone:        
Component:  strict-transport-sec           |     Version:        
 Severity:  Active WG Document             |    Keywords:        
-------------------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/7#comment:1>
websec <http://tools.ietf.org/websec/>