How effective is open source crypto?

[Anne & Lynn Wheeler]

At 08:40 AM 3/16/2003 -0800, Eric Rescorla wrote:
>You still need a round trip in order to prevent replay attacks. The
>fastest that things can be while still preserving the security
>properties of TLS is:
>
>ClientHello       ->
>ClientKeyExchange ->
>Finished          ->
>                   <-  ServerHello
>                   <-  Finished
>Data              ->
>
>See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002
>for a description of a scheme where the client caches the server's
>parameters for future use, which is essentially isomorphic
>to having the keys in the DNS as far as the SSL portion goes.
>
>In any case, the optimization you describe provides almost no
>performance improvement for the server because the load on the server
>derives almost entirely from the cryptography, not from transmitting
>the ServerHello [0]. What it does is provide reduced latency,
>but this is only of interest to the client, not the server,
>and really only matters on very constrained links.
>
>-Ekr
>
>[0] With the exception of the ephemeral modes, but they're simply
>impossible in the scheme you describe.

Sorry, there were two pieces being discussed.

The part about SSL being a burden/load on servers ....

and the shorten SSL description taken from another discussion. The shorten 
SSL description was (in fact) from a discussion of the round-trips and 
latency ... not particularly burden on the server. In the original 
discussion there was mention about HTTP requires TCP setup/teardown which 
is minimum seven packet exchange .... and any HTTPS chatter is in addition 
to that. VMTP, from rfc1045 is minimum five packet exchange, and XTP is 
minimum three packet exchange. A cached/dns SSL is still minimum seven 
packet exchange done over TCP (although XTP would reduce that to three 
packet exchange).

So what kind of replay attack is there. Looking at purely e-commerce ... 
there is no client authentication. Also, since the client always chooses a 
new, random key .... there is no replay attack on the client ... since the 
client always sends something new (random key) every time. That just leaves 
replay attacks on the server (repeatedly sending the same encrypted data).

As follow-up to doing the original e-commerce stuff ... we then went on to 
look at existing vulnerabilities and solutions .... and (at least) the 
payment system has other methods already in place with regard to getting 
duplicate transaction .... aka standards body for all payments (credit, 
debit, stored-value, etc) in all (electronic) environments (internet, 
point-of-sale, self-serve, face-to-face, etc), X9.59
http://www.garlic.com/~lynn/index.html#x959 (standard)
http://www.garlic.com/~lynn/index.html#aadsnacha (debit/atm network pilot)

Replay for simple information retrieval isn't particularly serious except 
as DOS .... but serious DOS can be done whether flooding is done with 
encrypted packets or non-encrypted packets. Another replay attack is 
transaction based ... where each transaction represents something like 
performing real world transaction (send a shirt and debit account). If it 
actually involves payment ... the payment infrastructure has provisions in 
place to handle repeat/replay and will reject. So primarily what is left 
.... are simple transaction oriented infrastructures that don't have their 
own mechanism for detecting replay/repeats and are relying on SSL.

I would also contend that this is significantly smaller exposure than 
self-signed certificates.




--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com