Subject: Re: [Ietf-krb-wg] Some Comments on preauth framework and OTP

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Jun 2010 17:10:45 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg>   1. An armor ticket can be obtained (only applicable to
    Greg> privileged initiators on keyed hosts).  2. Anonymous PKINIT is
    Greg> used to obtain an armor ticket (expensive in CPU).

    Greg> In the future there might be an EKE armor, but that's still
    Greg> expensive in CPU (though perhaps not quite as much as
    Greg> anonymous PKINIT).  As an implementor, I'm not sure if I can
    Greg> make a public key operation per user AS request the default
    Greg> mode of operation without creating performance problems.

I think that given that you can cash the armor TGT, the performance of
FAST is no worse than ssh, ssl or a lot of other technologies that
people seem to have no problem with.  So, my assumption is that a cached
PK op per user as-req is reasonable.

I think environments where performance is most critical are also
environments where expecting the platform to be able to cache the armor
ticket for a long time is also reasonable.

--Sam
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 3 Jun 2010 16:48:58 -0700

BTW, thanks for the explanations, Greg.

> ticket for a long time is also reasonable.

On the one hand, people seem to accept the overhead of PKI-based session startup.  On the other hand the acceptance seems to be predicated partly on the lack of viable alternatives.  (I'm saying this based on the Web https application.)  Furthermore most people who have a choice seem to turn off OCSP checking because it slows things down so much.

In a more general application, caching ought to be sufficient, I agree.  I'm not convinced that the the cpu overhead of symmetric/public key crypto is significant per se by the time you get to a complete system.  For example, if anonymous PKINIT requires you to do multiple OCSP checks, and the "privileged initiator" doesn't cache the resulting tgt, then I wouldn't try to deploy it.

I assume we don't disagree and I'm just running on at this point.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 21:36:49 +0200 (MEST)

Henry B. Hotz wrote:
> 
> On the one hand, people seem to accept the overhead of PKI-based session
> startup.  On the other hand the acceptance seems to be predicated partly
> on the lack of viable alternatives.  (I'm saying this based on the Web
> https application.)  Furthermore most people who have a choice seem to
> turn off OCSP checking because it slows things down so much.

OCSP is OK for running offline (i.e. store-and-forward) authentication,
like verifying digital signature on documents or maybe even XMLdsig.
But for performance- and availability-critical online authentication
the use of OCSP is a serious performance killer and a serious operational
risk.  (Although some folks need to bump their head several times
before they start realizing the obvious).

I remember one customer with serious performance problems who had
installed an "SSL accellerator" box in front of our application
--a special hardware box that works similar to a reverse proxy and
terminates the SSL communication with the client/browser and then
forwards the request (SSL re-encrypted) to a backend server
(or farm of servers).  I asked him for a diagnostic trace from
our backend application and that showed delays in the SSL handhshake
causes by that accellerator box.  Looking at the certificates that
the customer used between the box and the backend applications,
I noticed that he was using Certs with OCSP information in them.

I asked him to try using Certs without OCSP information in them
for this particular box<->backend link to see if it makes any difference.
It made a huge difference, around two magnitudes.

Killing your performance with less-than-optimal reverse proxies
is actually extremely easy as well as extremely common.  I've seen
several customers with out-of-the-box Apache reverse proxies taking
a two magnitude performance hit with the default configuration.
(mod_proxy lacks client-side TLS session caching to the backend
 for SSL reencryption, and usually HTTP/1.1 keep-alive is not enabled).

> 
> In a more general application, caching ought to be sufficient, I agree.
> I'm not convinced that the the cpu overhead of symmetric/public key
> crypto is significant per se by the time you get to a complete system.

Making TLS session caching work soothly is _always_ a good idea, because
the performance impact if it doesn't is huge.  For an abbreviated
TLS handshake (aka TLS session resume) on a 100 MBit/s LAN I typically
see 3 ms on the server for "SSL_accept()" on an accept()ed blocking socket,
even on older hardware.  For a full TLS handshake with 1024-bit RSA
server cert signed by RootCA, vanilla RSA ciphersuite and no certificate
revocation checking it is typically 30 ms for new hardware.

Does anyone have numbers for typical OCSP-based revocation checking
processing times?

-Martin