[websec] Issue #41

Yoav Nir <ynir@checkpoint.com> Mon, 26 March 2012 15:09 UTC

From: Yoav Nir <ynir@checkpoint.com>
To: "websec@ietf.org WG" <websec@ietf.org>
Date: Mon, 26 Mar 2012 17:09:22 +0200
Thread-Topic: Issue #41
Thread-Index: Ac0LYm3R7n9kKqNFR0KrH0OT5cN68A==
Message-ID: <9896F788-8F89-4483-AB38-D1702578C194@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [websec] Issue #41
Precedence: list

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] Issue #41 Yoav Nir