explicitly note revocation check failures as errors causing connection termination?

[jeff.hodges@…]

​http://www.ietf.org/mail-archive/web/websec/current/msg00306.html

Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
From: Adam Barth <ietf@…>
Date: Tue, 29 Mar 2011 14:35:58 -0700
To: Tom Ritter <tom@…>
Cc: websec@…

On Tue, Mar 29, 2011 at 2:29 PM, Tom Ritter <tom@…> wrote:

On Tue, Mar 29, 2011 at 4:58 PM, Adam Barth <ietf@…> wrote:

There's no coupling between HSTS and the particular algorithm a UA
uses to verify certificates.  The UA is free to use whatever
verification mechanism it desires.

This is good, but perhaps some clarification to the draft would be in order:

Section 2.2 states:

2.  The UA terminates, without user recourse, any secure transport

connection attempts upon any and all secure transport errors or
warnings, including those caused by a site presenting self-signed
certificates

If a self-signed certificate does not cause a secure transport error,
then you're all set. For example, it's fine for a self-signed
certificate to be in the list of explicitly trusted certificates. In
that case, no secure transport error is generated. Try it. :)

Knowing that HSTS allows any validation method a posteriori allows you
interpret this correctly - that self-signed certs *may* be allowed
under HSTS, if the user has added them to their store.  But without
that, it may be interpretted incorrectly - that no self-signed certs
would be allowed.

That's not what it says.

Furthermore, I'm not sure, but "any and all secure
transport errors or warnings" may be ambiguous.  I don't know if it's
an existing standard to enter a warning or error state in event of
(for example) a revocation check failure - although we do know that
most browsers do not present any warning or error.  There's more on
that in Adam Langley's thread.   If HSTS does not define whether or
not a revocation check failure is an error condition, I think it
should.

Indeed. A reference there would be helpful.