- From: Dan Simon <dansimon@microsoft.com>
- Date: Tue, 15 Oct 1996 16:07:41 -0700
- To: "'Tom Weinstein'" <tomw@netscape.com>
- Cc: Barb Fox <bfox@microsoft.com>, "'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] > >> 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. > >This is completely untrue. Although SSL 3.0 does not have a formal >mechanism for extension, such as the X protocol has, it does provide for >compatibility with future versions. Well, it has been pointed out to me that the latest SSL 3.0 errata sheet includes the addition of just such a mechanism--to wit: Section 7.6.1.2 For forward compatibility reasons, it's legal for a client hello message to have extra data after the compression methods. This data should be included in the handshake hashes, but otherwise ignored. This looks to me like exactly what I was looking for. Let's just hope that the TLS editors are more up-to-date than I am. >Why are >you flogging this dead horse? When last I checked, it was still alive, but apparently someone killed it while I wasn't looking. Apologies to all. Daniel Simon Cryptographer, Microsoft Corp. (dansimon@microsoft.com) > >
Received on Tuesday, 15 October 1996 20:58:00 UTC