[gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders tj at castaglia.org
Wed Jun 28 18:46:26 CEST 2017


> > then we should not
> > send the CertificateStatus message; the client would not know to look
> > for a CertificateStatus message unless there is also the
> > "status_request" extension in the ServerHello.
> 
> The server must use the ServerHello (and thus the ClientHello) of the
> original handshake as reference for the extensions:
> 
> "In this case, the functionality of these extensions negotiated during
> the original session initiation is applied to the resumed session."
> 
> During the initial handshake, both ClientHello and ServerHello contained
> the status_request extension, so the client is prepared to receive a
> CertificateStatus.

That is one interpretation, but not the only interpretation; "the
functionality of these extensions" is vague when applied in the context
of what happens during the handshake exchange itself.

> It's not stated explicitly in the RFC, but it follows for the client
> that the contents of the extensions list in the ServerHello of the
> resumed handshake are to be ignored, with the client having to use the
> extensions negotiated with the original ServerHello.

That is one possible reading, yes.  But not the only possible reading. 
YMMV.  It would be interesting to survey existing TLS client
implementations to see how many (if they even implement code for these
edge cases being discussed) do that, and how many not.  Since it is not
explicitly stated in the RFC, we are in the area of "undefined
behavior".

Cheers,
TJ



More information about the Gnutls-devel mailing list