Subject: Re: [websec] #42: STS exception for CRL fetching

From: =JeffH <[email-masked]>
Date: Thu, 14 Jun 2012 18:06:44 -0700

> This is about fetching CRLs from a domain that happens to be the same as
 > that of a website.
 >
 > Obviously you can't get a CRL or an OCSP response over HTTPS. Jeff's
 > response was that they should use a different domain name for the CRLs (if
 > they want to deploy HSTS)
 >
 > Obviously, it's too late to change AIA or CDP in existing certificates. But
 > I think it goes deeper. HSTS affects what the browser is doing. Different
 > resources from the same domain should all be protected by TLS. But we don't
 > expect this to affect things that are outside the browser, like email or
 > system updates. IMO the fetching of CRLs or OCSP responses is not part of
 > the browsing, but part of the HTTPS handshake. The fact that some browsers
 > implement both is besides the point. Internet Explorer uses an OS library to
 > do the TLS handshake, including any checking of revocation. In fact getting
 > the CRL fetch function to apply the HSTS policy would require extra effort
 > from the browser implementer.
 >
 > I think we should simply say that HSTS does not apply to non-content.
 > Fetching CRLs or browser software updates is not content, and HSTS should
 > not apply to it.

Unfortunately, we would then have to define what comprises "content", and 
that's a huge rathole I think we should unequivocally avoid.

I've taken a (ad-hoc, limited, unscientific) look at the AIA and CDP in some 
existing certificates (from major CAs), and all of the ones I checked used a 
dedicated subdomain for their OCSP responder, e.g...

   evsecure-crl.verisign.com
   evsecure-ocsp.verisign.com
   SVRSecure-G3-crl.verisign.com
   ocsp.verisign.com
   ocsp.thawte.com
   crl.thawte.com

So in order not to cause themselves and their customers problems, CAs simply 
shouldn't issue HSTS policy with "includsubdomains" from their top-level domain 
name, and they will be fine. This is already discussed in S 10.3 of the HSTS 
draft.

HTH,

=JeffH

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 16 Jun 2012 20:19:09 +0100

<hat="individual">
+1. I would agree with Jeff on that.
(Mostly because I see no other good solution.)
Any other comments/ideas on this one?

Best regards, Tobias

On 15/06/12 02:06, =JeffH wrote:
> Unfortunately, we would then have to define what comprises "content", 
> and that's a huge rathole I think we should unequivocally avoid.
>
> I've taken a (ad-hoc, limited, unscientific) look at the AIA and CDP 
> in some existing certificates (from major CAs), and all of the ones I 
> checked used a dedicated subdomain for their OCSP responder, e.g...
>
> So in order not to cause themselves and their customers problems, CAs 
> simply shouldn't issue HSTS policy with "includsubdomains" from their 
> top-level domain name, and they will be fine. This is already 
> discussed in S 10.3 of the HSTS draft.
>
> HTH,
>
> =JeffH
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Jun 2012 10:46:27 +0100

> <hat="individual">

Same here in this message.

> Any other comments/ideas on this one?

I tend to think that "don't use this hammer if it doesn't suit you" is the best answer here. Exceptions are bad (hard to handle properly).

>> Unfortunately, we would then have to define what comprises "content", and that's a huge rathole I think we should unequivocally avoid.
>> 
>> I've taken a (ad-hoc, limited, unscientific) look at the AIA and CDP in some existing certificates (from major CAs), and all of the ones I checked used a dedicated subdomain for their OCSP responder, e.g...
>> 
>> So in order not to cause themselves and their customers problems, CAs simply shouldn't issue HSTS policy with "includsubdomains" from their top-level domain name, and they will be fine. This is already discussed in S 10.3 of the HSTS draft.
>> 
>> HTH,
>> 
>> =JeffH