Re: [TLS] OCSP must staple

I agree with Ryan.  In my view, if must staple is present, the server
operator is requiring a stapled response and specially requesting the client
not to communicate with the CA.  In that case, the connection should fail
instead of using a fallback. The RFC language already reflects this:

If the TLS status_request feature is specified in the TLS Feature
   extension and a TLS client specifies the status_request feature in
   the Client Hello, a server MUST return a valid OCSP token for the
   specified server's End Entity certificate in the response.

Also in Section 2:
The inclusion of a TLS feature extension advertising the
   status_request feature in the server end entity certificate permits a
   client to fail immediately if the certificate status information is
   not provided by the server.  

Jeremy

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ryan Sleevi
Sent: Sunday, June 8, 2014 10:15 PM
To: Tom Ritter
Cc: tls@ietf.org
Subject: Re: [TLS] OCSP must staple

On Sat, June 7, 2014 10:10 pm, Tom Ritter wrote:

>  While it looks some of the semantics of 'Must Staple', I think either  
> behavior could be acceptable for a client.  Either closing the 
> connection  without attempting to contact a OCSP server, or switching to a
'Hard Fail'
>  OCSP lookup.
>
>  I can imagine some servers deciding that they would want clients to 
> fail  if  they didn't send a staple, rather than leak the OCSP lookup 
> to the CA.  I  could imagine other servers wanting to hedge their bets 
> and have the  client  make an attempt before giving up.
>
>  I don't understand what you mean by the OCSP server rejcting them.

It's not really "must staple" if clients fall back to doing lookups, is it?
It's more like "should consider staple" (RFC 6919)

I would expect conforming clients to fail if must-staple is present but not
stapled. This includes ignoring OCSP cached responses, and prevents online
lookups.

This interpretation is key among the reasons why Chrom{e/ium} has not
(yet) begun experimenting with must staple, since the APIs used don't offer
as much flexibility. However, that interpretation is exactly what ensures
interoperability - these sorts of "soft fallbacks" cause a number of issues,
as everyone in the TLS WG can attest to elsewhere (eg: TLS version rollback,
AIA chasing, etc)

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls