Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

[Martin Rex <[e-mail]>]

Nelson B Bolyard wrote:
> 
> > The following URL says "SPEC":
> > http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM
> > This URL says "Draft":
> > http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302.txt
> > 
> > and includes an _explicit_ expiration of May 1997.
> 
> Yes, all the drafts expired, including the one that says "spec".

Nope.  The one calles SPEC does NOT have an expiration.

When I complained to the supplier of our OEM SSL implementation about
an interop problem with TLS (not extension, only { 0x03, 0x01 }) in
August 2000, then they told me that the behaviour was according to
the SSLv3 spec.

I asked them for their spec document, and it was the March document.
So I went to www.netscape.com and used their "Site Search", and the
only document it found was the pretty (short) version of the SSLv3 spec.

Then I saw the reference to a Nov 18th document in the TLSv1.0 spec
(but not the slightest hint where to find it), and thats when I
downloaded the ietf-tls discussion list archive and found the document
attached to a posting from Win Treese (that attachment seems to have
been stripped in the current archive, it was attached to this message.

http://www.imc.org/ietf-tls/mail-archive/msg00422.html

And although Win wrote this:
"For a variety of reasons, it's important to have this draft for the record."

neither TLS WG nor Netscape did anything substantial to keep
this document on record.

When I found that draft, I sent it to our supplier, so they would
use it.  But I could not blame them for not being aware of a newer
document, because it was obviously a big mess and no one cared.


> 
> > http://www.imc.org/ietf-tls/mail-archive/msg00325.html
> > 
> >   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.
> > 
> >   -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt
> 
> Tom and I shared a cubicle.  His brother Jeff sat in the next cubicle over.
> One of my first mistakes in working on NSS's SSL code was changing the code
> for handling received client hellos to require that the length of the
> message be exact, with no extra.  Tom caught this mistake in his review of
> my patch.

I do believe that.  If you look at the TLS mailing list archives,
Tom was flamed violently for making such a statement.  He sure hadn't
forgotten that.   But as you can see in the referenced message above,
Barb Fox (Microsft) clearly points out that _NONE_ of the installed
base of SSLv3 in Oct-1996 was extensible and neither was there
an SSLv3 spec available providing this extensibility.


> 
> > You could have removed the explicit expiration notice on draft302.txt
> > and you could have renamed it to "3.0 final SPEC", you could have
> > removed the version that you condered outdated--or at least clearly
> > marked it as outdated _in_the_document_ if that was what you or
> > Netscape intended it to be.
> 
> I consciously chose to make NO changes at all to any of those documents,
> lest anyone accuse Netscape of continuing to try to revise the SSL 3.0
> specification rather than (or in parallel with) adopting the TLS 1.0
> specification.


Regrettably you did _NOT_ remove the expiration tag from the draft302
and did _NOT_ take down the outdated draft either.

You should have put up the "Beware of the Leopard" sign on your
overview page to make the picture complete.

-Martin