On 17/11/2011 07:09, Yoav Nir wrote:
Hi
Hi Yaov,
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.
+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>:
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.
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 some are proposing for TLS, but I think we
should explicitly say that this should apply only to HTTP application content.
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)?
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
