JEP Review Request: OCSP Stapling for TLS

[Jamil Nimeh]

Hello Bernd, thanks for the quick feedback!  I don't have concrete 
answers to all your questions at this point, but I'll address what I can 
in-line.

On 09/02/2014 05:47 PM, Bernd Eckenfels wrote:
> 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?
JJN: We don't have a draft for all the tunables yet.  Right now I'm 
collecting all the items that we'd want to be able to tweak, so 
suggestions are certainly welcome.  Your note below about an option to 
deny or ignore incoming requests with nonces is an interesting one that 
I had not considered.  Most of the TLS clients I've seen that even do 
status_request don't bother with nonces or extensions of any type, I 
would assume for the performance reasons you hinted at below.  To be 
fair, all the clients I've looked at that make status requests have been 
browsers and openssl s_client.  Perhaps there are other TLS clients that 
make use of ResponderIds and/or extensions that I have yet to see.
>
> 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?
JJN: I'd like to have the server honor it if possible, though I don't 
think I called it out in the description portion of the JEP. In my 
prototyping so far with Apache 2.4 I haven't populated a request with a 
ResponderId yet, though I have the hooks to do so. It would be 
interesting to see how they handle it.
>
> (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()?
JJN: I'm also rethinking this, though I don't want to say more than that 
right now only because I don't have a clear picture yet of what any 
programmatic interface would look like.  Up to now I've been thinking 
properties, but I'd like to avoid a case where we make too many of 
those.  Also you brought up a very good point about being able to turn 
it on/off on a per-destination basis.

Thanks once again for sharing your thoughts on this, and I welcome 
further comments on the topic.

--Jamil
>
> 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