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

Eric Rescorla <ekr@networkresonance.com> Sat, 06 January 2007 02:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Zs-0008C3-Ja; Fri, 05 Jan 2007 21:46:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Zr-0008Bu-Ej for tls@ietf.org; Fri, 05 Jan 2007 21:46:35 -0500
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31Zq-0008WN-2p for tls@ietf.org; Fri, 05 Jan 2007 21:46:35 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2D1011E8C5D; Fri, 5 Jan 2007 18:46:33 -0800 (PST)
To: Mark Brown <mark@redphonesecurity.com>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00
References: <00aa01c7313a$ed9c34d0$6801a8c0@rps.local>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Fri, 05 Jan 2007 18:46:33 -0800
In-Reply-To: <00aa01c7313a$ed9c34d0$6801a8c0@rps.local> (Mark Brown's message of "Fri, 5 Jan 2007 20:32:36 -0600")
Message-ID: <86mz4wan3q.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

"Mark Brown" <mark@redphonesecurity.com> writes:

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

Yes, but *now* you're in the business of having the application
require tight control of when signatures are created and when
they're available, which brings us back to the situation I
was complaining about in my initial review, where this isn't
just automatic, it requires esxtensively modifying the
app, plus the race condition/lockstep issues I raised in my
original review.


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

I totally agree with that. That's the virtue of a message signing
scheme like S/MIME.


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

It depends what you're measuring, latency or CPU time. The dominant
CPU cost of SSL/TLS is the RSA key exchange (which is commensurate cost
with signing, of course)[0]. Providing evidence (independent signatures)
for a single request/response pair entails that the server do two 
additional signatures (one in response to the Evidence-Request for
the client request and one in its Evidence-Request for the response).
This substantially increases the server load quite a bit beyond the
symmetric crypto cost. And of course there's no guarantee that
a request or response goes in a single TLS record, which may or
may not be the case.

-Ekr

[0] C. Coarfa, P. Druschel, and D. Wallach. Performance Analysis of
TLS Web Servers. In Proceedings of NDSS '02, 2002. 0

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