Subject: [TLS] draft-hallambaker-tlsfeature-02

From: "Ben Wilson" <[email-masked]>
Date: Tue, 28 May 2013 11:11:33 -0600

What if the CA / Browser Forum were to add an optional provision for the
certificate profile of End Entity TLS Certificates that said the following?

TLS Feature Extension (optional)

Subscriber Certificates MAY contain the TLS Feature Extension advertising
that the status_request feature of OCSP stapling is available and supported
by the subscriber.  If present, this field MUST NOT be marked critical. 

See http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 29 May 2013 09:58:03 +0200

> See http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 

What is the actual problem the TLS extension on this draft solves?
A client doesn't need an extension to drop the connection if an OCSP
reply cannot be obtained. Moreover there are very few cases where a
server would like to force the client to disconnect if such a reply is
not available since the CA's OCSP server is typically outside its
control, and which server administrator would like his site to go down
every time the CA's server goes down.

For the latter if the server is really concerned about the client
getting the OCSP replies, he can send them in-band anyway using the
status request extension (and if the server doesn't support this
extension - as mentioned in the draft - why would it support the new one?)

regards,
Nikos

---

From: Tom Ritter <[email-masked]>
Date: Wed, 29 May 2013 12:22:04 -0400

On 29 May 2013 03:58, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> reply cannot be obtained.

It also doesn't need to be told to not downgrade TLS versions, or to
require revocation informatton at all - but they don't do those
things.

> Moreover there are very few cases where a

"Very few" is probably accurate, but this is explicitly for those cases.

> extension - as mentioned in the draft - why would it support the new one?)

Exactly, the server will do that.

> What is the actual problem the TLS extension on this draft solves?

The problem is that every web browser and client will happily continue
on without revocation information if it is given an x.509 certificate
in a TLS handshake.  By placing a flag in the certificate, the clients
who recognize the flag will know they should not (MUST NOT?) continue
without revocation information.  If clients were to flip that switch
for every single certificate it saw - vast swathes of HTTPS site would
not work.  So clients will not do it.  But this flag is a way for a
site to signal to a client that it does not want to be bug-compatible
with the rest of the Internet, and wants to hold itself to the correct
standard.  An opt-in mechanism.  And clients can flip that switch and
hold sites to a higher standard if it is an opt-in mechanism.

-tom