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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Sep 18, 2014 at 5:25 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> On Sat, 2014-09-13 at 20:20 -0500, Tom Ritter wrote:
>> On 5 September 2014 10:34, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> > I don't see how it does close the door. What should the client do if the
>> > server administrator sets up an old version of a valid ocsp staple?
>>
>> Section 3.1.1 specifies "a server MUST return a valid OCSP token".   I
>> would consider an expired ocsp staple to not actually be valid.  I
>> would refer to it as expired, with the implication that the signature
>> is correct, because if it wasn't a person probably would have said
>> that in addition to describing it as expired.
>
> That's pretty sketchy. OCSP responses have a recommended validity
> interval, this is not the same as X.509 certificate expiration. I'm not
> sure what popular browsers do with responses received by the server that
> are outside the validity period, but I would be very surprised if they
> dropped the connection. If in this document it is assumed that responses
> not within the recommended interval should cause a TLS connection
> failure, it should be explicit.

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.

Dropping the connection is only one response that might be appropriate.

For example, if a certificate is presented during an SMPT STARTTLS
upgrade. Do we want to abort the connection if the certificate is
expired or revoked? Well maybe we do but what if we would have
delivered the message without TLS at all.

In the Web browser case we might also be in an opportunistic
encryption situation. We might drop out the security indicator for a
revoked cert in that case.

We can certainly tell the server that if the feature extension is
present the server MUST be in compliance. Because failure to comply is
almost certain to result in a compatibility issue. That compatibility
issue may be less than rejection of the connection but client is in
its rights to do that.

I don't think we can specify compliance requirements on the client. We
can provide the client with information and tell the client how to
interpret is but we can't mandate anything more.