- From: Dan Simon <dansimon@microsoft.com>
- Date: Mon, 14 Oct 1996 15:30:20 -0700
- To: Barb Fox <bfox@microsoft.com>, "'Tom Weinstein'" <tomw@netscape.com>
- Cc: "'elgamal@netscape.com'" <elgamal@netscape.com>, "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'treese@OpenMarket.com'" <treese@OpenMarket.com>, "'david.brownell@Eng.Sun.COM'" <david.brownell@Eng.Sun.COM>
>From: Tom Weinstein[SMTP:tomw@netscape.com] > >The lack of a general extension mechanism in SSL v3 is a feature, not a >bug. This is a security protocol, and so susceptibility to analysis is >a good thing. Simplicity and rigidity are features here. SSL does >provide for forwards compatibility by allowing version negotiation and >protection from version rollback attacks. > No one is suggesting that complex extra features be added willy-nilly without careful consideration of their security implications. However, to neglect to account for possible (and possibly necessary) improvements in the protocol beyond those that can be addressed by versioning (particularly possible changes to the first handshake message sent) would be, in my opinion, sheer reckless hubris. SSL 3.0 currently lacks, and TLS desperately needs, a mechanism for incorporating such improvements. Right now, most of the world still uses a completely inadequate SSL 2.0 client hello, and is forced to play weird nonstandard tricks with what would otherwise be a perfectly standard PKCS public-key encryption, all because of SSL 2.0's lack of extensibility. Please, let us learn from past mistakes. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com
Received on Monday, 14 October 1996 18:33:08 UTC