[14570] in cryptography@c2.net mail archive
Re: Simple SSL/TLS - Some Questions
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Tue Oct 7 16:19:47 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: Jill Ramonsky <Jill.Ramonsky@aculab.com>,
cryptography@metzdowd.com
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: 07 Oct 2003 12:09:16 -0700
In-Reply-To: <4.2.2.20031007123924.00ac2ef0@mail.earthlink.net>
Anne & Lynn Wheeler <lynn@garlic.com> writes:
> the client generates a random session key according to the crypto
> preferences, encrypts a credit card number and misc. ancillary
> transaction info with the session key, encrypts the session key with
> the public key (if you really want to simplify to the business
> requirements, directly encrypt with the public key and eliminate the
> session key step)
This doesn't provide equivalent services to TLS--no anti-replay
service for the server.
> .... and use a XTP-like (or some of the emerging
> real-time protocol) .... aka existing SSL is carried on top of TCP
> .... TCP requires a minimum of 7 packet exchange .... and SSL on top
> of that then requires all the negotiation chatter.
With the result that it is now screened out by your current
firewall policies. Good idea.
> This is about as simplified SSL/TLS as you can get based on business
> requirements for the major existing applications using SSL/TLS
This also isn't TLS. It's a protocol that bears some vague resemblence
to TLS.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
