JEP Review Request: OCSP Stapling for TLS

[Bernd Eckenfels]

hello,

this is good news!

jut a quick question before I prepare a full response.

There is a "tunables" section mentioned in the JIRA which is not very
concrete, is there a draft somewhere for it?

Because, I would add as a sample/recommended tunable the option to deny
for ServerSockets to respond to requests with nonces, as this is a
major DOS risk and most of the good properties of OCSP stapling wont be
present if a client requests it. Instead of denying it might also be OK
to ignore it, as the per RFC6066 passing request_extension(ocsp-nonce)
is a SHOULD in 6961 an "conditional MUST".

I guess the responderID will not be honored by the server
implementation?

(and it is a shame that 6066 and 6961 do not mention the most typical
use case with no responderid, no nonce and a single OCSP response
provided by the CA issuing the intermediate as well, therefore no
multiple-response is needed. I guess the client will not sent a nonce
by default (or not at all?)).

Also I can understand the restriction to not require API changes I
wonder if this is a good idea. I will come back to that later, but just
a prelimiary question: will a TrustManager (or HostnameVerifier)  be 
able to actually see and work on the OCSP response - maybe via
getHandshakeSession()?

In the case I have to connect to a larger number of remote servers it
would be good for me to turn the request of on a destination base. With
a security/system property thats not so easy. In case of SNI I could
work around by constructing the client socket with no hostname, but I
really wish both features could be controlled dynamically.

Greetings
Bernd


Am Tue, 02 Sep 2014 14:15:45 -0700 schrieb Jamil Nimeh
<jamil.j.nimeh at oracle.com>:

> Hello all,
> 
> The draft JEP "OCSP Stapling for TLS" has been opened up for
> community review.  This is an update to the original call for
> comments back in mid-March this year[*].  Like some of the other
> early JEPs this year, this has been brought under the JEP 2.0 process.
> 
> https://bugs.openjdk.java.net/browse/JDK-8046321
> 
> Thank you,
> --Jamil
> 
> *
> http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010327.html