On Wed, Dec 19, 2018 at 01:40:43PM -0500, Viktor Dukhovni wrote:
> To that end, please post a "tshark" decode of a TLS 1.2 handshake
> (thus avoiding encrypted handshake records that make much of the
> TLS 1.3 handshake opaque, and your tshark may not yet support TLS
> 1.3). With reference to that handshake explain what you'd like
> to see happen differently on either the client or server end.
That said, there is no mechanism for servers to request OCSP stapling
from clients in TLS 1.2 and below. The TLS 1.2 CertificateRequest
message is a fixed structure with no room for extensions, such as
needed to request OCSP stapling from clients:
https://tools.ietf.org/html/rfc5246#section-7.4.4
so if you're looking for an implementation of (and API to trigger)
the "status_request" extension for the TLS 1.3 CertificateRequest
message, that'd of course be specific to TLS 1.3, and would likely
be a new feature.
Support for OCSP stapling in OpenSSL is IIRC presently rather
anaemic. An interface is provided for applications to examine and
validate OCSP messages, but nothing exists to ask the library to
do that internally. The interfaces are subtle, and some applications
go through the motions, but get the details wrong. IIRC curl (i.e.
libcurl) is one of the few places where the code looked right after
a cursory review.
So before the existing OCSP stapling support is extended in the
client-to-server direction, I'd rather see more robust support for
handling the OCSP status extension inside the library, so that
client applications can just ask for one of:
* Mandatory OCSP stapling
* Conditional OCSP stapling (based on must-staple in the certificate)
* Ignore OCSP stapling (regardless of must-staple in the certificate)
and have all the details handled in the library. Once that's done,
one might ask for the reverse direction in TLS 1.3.
--
Viktor.
P.S. personal soapbox:
FWIW, OCSP is IMHO too fragile for too little benefit, and I've
steered well clear of it in Postfix. OCSP has and will likely for
some time continue to have insecure fallback modes (the attacker
won't ask for a must-staple certificate, and most CAs will not
refuse to issue certificates without must-staple). So what you get
is more opportunities to fail, and little meaningful security gain.
What I'd rather see is automation of certificate rotation, and
increasingly (decreasingly?) short certificate lifetimes as
with Let's Encrypt. I think that in practice that's more beneficial
than OCSP.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
