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

From: "Mark Brown" <[email-masked]>
Date: Fri, 5 Jan 2007 20:33:22 -0600

Eric,

> I think "not great" is quite an understatement here. You've just
> required that every TLS record write requires *two* signatures,
> one from the sender and one from the receiver. This includes
> record read/writes which the application doesn't even care
> about having evidence for. Your typical brokerage transaction
> requires 10s if not hundreds of separate HTTP fetches, each
> of which requires one or more record in each direction. Doing
> 25 digital signatures for every transaction is an enormous
> load on the server.

Turn on TLS Evidence only for one POST, skip the GETs.  There's typically
one important POST per transaction, the one before the
print-this-page-for-your-records response.  That's the page the user
typically prints for evidence of the transaction, despite its failings.

It doesn't make sense to create TLS Evidence for every fetch.  What would be
the point of being able to show for posterity that some browser downloaded
20 gifs, a css file and two javascript files?  None.

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.  

--mark

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Mon, 8 Jan 2007 20:28:35 +0100 (MET)

> 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