Subject: [websec] Issue #41

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Mar 2012 17:09:22 +0200

Hi

It was my review that triggered this, so I'd like to explain my position.

There are several things that could be considered failures of the TLS layer:
 1. Revoked certificate
 2. No CRL/OCSP response
 3. Expired certificate
 4. Expired CRL (yes, I know NextUpdate is not expiry…)
 5. Mismatch between hostname and certificate (CN or alt name)
 6. Some other things I forgot?

I believe we all agree that #1 should be a hard fail. Maybe even in the absence of HSTS. #2 is usually not treated as a failure today - it doesn't trigger a warning screen in any browser. I haven't tested this with HSTS, but I'd be surprised if this causes a hard fail. Same for #4.

AFAIK the most common failure cases are #3 and #5. Certificates do expire, and even some well-run, security conscious site administrators have been known to let them expire. 
Mismatching domain names is an issue, because two FQDNs might point to the same server. IMO this is a good argument for a report-only setting, whereas the expiry is something that will bite you far after your supposedly successful deployment.

I guess my issue with this is because when I read the draft for the first time, I thought this would be a good idea for websites that only do HTTPS and do not do HTTP except to redirect to HTTPS. I thought it would allow them to signal this information, and allow them to defeat HTTP-based MiTM attacks. The draft as it stands is not a good fit for this use case, because it requires more of the administrator than is currently reasonable to expect.

I could propose an "HSTS-light" header for this use case, but I don't think anybody would like to have that. 

Yoav