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.ni...@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
