N$ SSL vs M$ PCT

[rah@shipwright.com (Robert Hettinga)]

--- begin forwarded text

From: "John Hemming CEO MarketNet"  <JohnHemming@mkn.co.uk>
Date:  Sun, 01 Oct 1995 20:36:31 PM PDT
To: www-buyinfo@allegra.att.com
Mime-Version: 1.0
Subject: N$ SSL vs M$ PCT

Having found that Micro$oft have produced a standards document
about their alternative to SSL I was interested in comparing it to
that written by Net$cape.

The big question in my view is why did they produce a new
proposal is it:

a) Because they have found major flaws in the SSL protocol
and wish to correct these (note the protocol not the implementation)

or is it

b) Because M$ want to "own" the Internet Security Software market
and take the initiative off N$ who, notwithstanding their problems with
implementation, have produced a working system.

My personal view is that b) is the case.

Comparison

I have compared
SSL V3 <draft-hickman-netscape-sl-01.txt>  (available at www.netscape.com)
PCT http://www.microsoft.com/windows/ie/pct.htm <draft-microsoft-PCT-91.txt>
Both have status of Internet Draft.
I have implemented SSL V2 in a browser
(ftp://193.119.26.70/mktnet/pub/horse.zip)
and a server (https://alpha.mkn.co.uk/)
I have not implemented and do not intend implementing PCT

Both SSL V3 and PCT now involve a vast number of different alternatives
for Ciphers most of these alternatives do not help in any practical sense
and I have not compared the lists.

PCT allows for supporting SSL as well by using a bit in the SSL version number
to indicate PCT.  This means that servers can support both protocols. Clients
cannot as the first message is sent by the client and there is no provision for
SSL/PCT negotiation.

Both PCT and SSL start with an initial session (GET or POST in wwwland) which
establishes a master key and allow continuations of that key in later sessions.

M$ use the following arguments in support of PCT:
1. it is simpler.
PCT uses longer messages with more fields in them.  It cuts out the final
SERVER-FINISHED and CLIENT-FINISHED messages.  It puts some of the
data in SSL into other records.  I quite like the verification in the
CLIENT-FINISHED
message which means that bad implementatations crash out at that point rather
than putting rubbish into the higher level protocol.  However, I consider that
in essence there is no real difference.  I, therefore, disagree with M$.

2. Message authentication uses different keys to the encryption keys.  How
this helps, apart from making implementation harder, I cannot quite fathom.  We
should not be using this secure channel protocol for proper message
authentication
only.  The MAC (Message Authentication Code) is not what I would use for
authentication from a legal and contractual background.  I prefer Digitally
Signed
Instructions.

3. They say there is a security hole in SSL's client authentication.
When the initial session establishing a session key uses (for example) 40 bit
encryption. It does mean that subsequent sessions are also essentially just as
insecure.  This is the case for PCT and SSL.  However, client authentication
in SSL uses a digital signature using the client's private key.  To get hold of
this requires something more than simply being man in the middle.  I think M$
are well out of order on this one.

4. They introduce a verify prelude field to make sure that the cipher type
and other negotiations have not been tampered with.  I suppose this is a
fair if disingenuous point.  If a "man in the middle" is tampering with your
negotiations to make sure that you use a low level of encryption so that it
can be cracked then your implementations should not be using such
crippleware and cypherpunks will have cracked it ages ago.

There is a point that should be made that servers and clients should really
indicate the encryption cipher being used.  Both my client and server do.

So in essence M$ make 4 arguments. Two are IMHO wrong.  One is
irrelevant from a commercial perspective and the other one does not matter.

In the end N$'s version is working.  M$ are probably coding like mad.

The final formula to determine the result may be

if (M$>N$) SSL+=PCT;

where M$ and N$ are measured in US Dollars.

(MarketN�t is a UK company independent of both M$ and N$ although
N$ were helpful in debugging the interoperability of my early essays into
SSL for which I am grateful.)

--- end forwarded text


-----------------
Robert Hettinga (rah@shipwright.com)
Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
USA (617) 323-7923
"Reality is not optional." --Thomas Sowell
>>>>Phree Phil: Email: zldf@clark.net  http://www.netresponse.com/zldf <<<<<