Re: [TLS] New version of the TLS feature draft

[Viktor Dukhovni <[e-mail]>]

On Mon, Sep 22, 2014 at 03:10:53PM -0400, Phillip Hallam-Baker wrote:

> >> Given that we currently have a situation where the vast majority of
> >> Web browsers are not PKIX compliant and ignore revocation information
> >> completely and Web browsers are only one PKIX application, I don't
> >> think it is appropriate to use a MUST here to direct how invalid
> >> status is handled.
> >
> > Maybe not, but it makes sense to define what is valid and invalid.
> > The problem statement of this draft as you set it is to close a door on
> > a "downgrade" attack where no OCSP response is sent. However, if you
> > don't define what is a secure connection to a server that supports OCSP
> > status request, how can you claim to fix an attack?
> 
> The draft is designed to allow the client to close the door on the
> downgrade attack. That meets the problem statement, I think.

I strongly agree, but perhaps we should provide a more detailed
answer...

Yes of course the draft can't mandate that the client must fail,
since as you note the client might be doing opportunistic STARTTLS,
and the TLS session should be established in that case, even if
stapled data is missing or expired.

Therefore, the TLS library cannot unconditionally enforce the
requirements of the draft by shutting down the connection or the
like.

However the TLS library can and should signal a failure to verify
the peer certificate chain.  Clients that proceed despite such
failure can continue to establish the session, while clients that
want an authenticated peer may elect to abort the TLS session, or
to complete it and then gracefully perform an application-level
abort, ...

So there is room to say that servers that fail to present an expected
sufficiently fresh stapled OCSP response MUST NOT be considered to
have a valid certificate chain.  What happens after that is up to
the application.

Such a statement would help library implementors do the right thing,
(signal verification failure) and avoid both inadvertently ignoring
the problem as well as over-reaction that might needlessly degrade
opportunistic clients to cleartext.

-- 
	Viktor.