W3C home > Mailing lists > Public > ietf-tls@w3.org > October to December 1996

RE: Extensibility

From: Dan Simon <dansimon@microsoft.com>
Date: Tue, 15 Oct 1996 16:07:41 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-92-MSG-961015230741Z-25775@mail4.microsoft.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC