Re: [TLS] Please discuss: draft-housley-evidence-extns-00

[Martin Rex <martin.rex@xxxxxxx>]

Mark Brown wrote:
> 
> Regarding performance estimates, whether you use a FIPS 140 accelerator or
> not, the cost of two digital signatures and the extra TLS Evidence messages
> is less than the 20+ round trips made to load the page, even if the client
> is using multiple connections.  

In the past I have seen 2 measurements with hardware crypto involved in
digital signature generation for use in a backend application server,
and both times, the price was high and the performance was unconvincing.

One was a crypto hardware on a PCI extension board for PCs being used
for an SPKM1 mechanism, and the other was an NCipher crypto box
with SCSI-Interface being used for the Server side of SSL.

The were two problems:

(1) latency setting up the crypto hardware for each individual operation.
    for the SPKM1 mechanism using digital-signature based MICs, this
    resulted in 9milliseconds per message protection call.

(2) doesn't scale as well as multi-core/multi-CPU setups that are
    being used these days.
    I my test setup, a current dual-Xeon (plus HT) running Linux
    machine was just as fast as an older dual-CPU Solaris workstation
    with the SCSI-attached NCipher box.

Longer RSA keys will favour the hardware approach, but still, the
performance/price ratio of the crypto hardware seems to have
difficulty competing with raw CPU horsepower, especially for
blade-size&cost server setups.

The bottleneck in some of the entry-level crypto hardware solutions
might be in the smartcard interface (io speed).

And the performance of serial SmartCard readers for end users
performing RSA crypto operations is > 100x slower than software-based
RSA on a PC, so you really don't want to have any of these participating
every roundtrip of your communication.


Btw. in some scenarios, when clients are authenticated based
on X.509 certs (e.g. on an SSL/TLS Web Server) it might at least as
important to protect the list of trust anchors from tampering
as to guard the servers keypair...


-Martin

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls