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 _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
