Subject: [websec] Regarding HSTS issue #4

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2011 09:09:11 +0200

Hi

I thought I would go over the list of issues for HSTS, and got stuck on the first one (#4).

The issue headline is as follows "Clarify that HSTS policy applies to entire host (all ports)"

The text in draft -01 that addresses this is in section 7.2:
   Note that the implication of the above steps is that the HSTS policy
   applies to all TCP ports on a host advertising the HSTS policy.

I have two issues with this. First, this does not allow to all *TCP* ports, only HTTP ports. We don't care about some SSH or FTP port. The text above that paragraph does say this, but I would remove sweeping references to TCP.

The other issue is that I can think of a use case where it would be OK to use HTTP (no S) on another port, and <disclosure type="full"> my company makes a product with such a use case </disclosure>:

A web server might be also running a CA, and that CA may issue a certificate for the website. But what is more relevant, the CRL DP for that certificate may be co-located with the web site. CRLs (or OCSP responses) need to received in the clear, otherwise you have a bootstrapping problem, so in that case, fetching the CRL needs an exception, even though it is to a host that advertises HSTS.

I don't believe this is really an issue for implementers. Fetching CRLs is usually done in a different context from the fetching of content, and the same could be said for hash&URL schemes that some are proposing for TLS, but I think we should explicitly say that this should apply only to HTTP application content.

Yoav

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Nov 2011 08:34:03 +0000

> Hi
Hi Yaov,
> I have two issues with this. First, this does not allow to all *TCP* ports, only HTTP ports. We don't care about some SSH or FTP port. The text above that paragraph does say this, but I would remov…
+1.
> The other issue is that I can think of a use case where it would be OK to use HTTP (no S) on another port, and<disclosure type="full">  my company makes a product with such a use case</disclosure>:
>
Right.
> I don't believe this is really an issue for implementers. Fetching CRLs is usually done in a different context from the fetching of content, and the same could be said for hash&URL schemes that som…
If I were to add some text to describe this, I wouldn't use "HTTP 
application content", as this is still sounds ambiguos to me.

Is your recommendation to exclude protocols running over HTTP (as 
opposed to classical HTTP use)?

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Nov 2011 13:56:16 +0200

> opposed to classical HTTP use)?

I guess so, but web services should probably also be protected under HSTS. CRL and OCSP fetching are special cases that are never protected by TLS because their content is signed and because it would cause a bootstrap problem.