Re: Merged Transport Layer Protocol Development

Here are some preliminary comments on:

> Microsoft Strawman Proposal for a
> Secure Transport Layer Protocol ("STLP")
> 
> Discussion Draft 1.0
> April 8, 1996
> 
> [...]
> To expedite this process, Microsoft and Netscape have agreed to start
> face-to-face discussions with the objective of presenting a viable
> draft proposal to the IETF working group at its next meeting in June.

This is the best news I've heard all week!  Ran Atkinson recently
commented on the One Time Password working group:

 "PS: Its a credit to Neil and the WG members that the OTP WG is easily the
  most harmonious working group in the IETF since the late 1980s.  Once
  upon a time, many working groups were as nice as OTP.  In modern days,
  few are."

The release of this discussion draft, and the agreement of the major
participants to cooperate on the development of a proposal, bodes well
for the prospects of this group to accomplish it's task in a similar
spirit.


> (1) There is no significant implementation cost for separate
> negotiation of the message digest algorithm and the bulk cypher.  In
> fact, the code could be better if they were separate; instead of one
> large table  with a lot of repetition between entries there would be
> two small tables with no repetition.

Agreed.  The message digest algorithm (hash function) is used in several
places - the Message Authentication Code (MAC), derivation of keying
material, certificate signatures, handshake finished message, etc.
I don't see any need to bundle together the MAC hash function and the
bulk cipher, and haven't seen any compelling arguments that unanalyzed
combinations of MAC and bulk cipher might lead to cryptographic weakness.


> (3) Provide a stronger error reportage.  If a packet is refused, there
> should be notification.  The hardest thing in implementing SSL is
> figuring out why some anonymous server refused your record.  Also, it
> is desirable to be able to explain to the user what the problem is.

Agreed in principle, however I don't understand the specific proposal
in this draft.  Section 4 contains:

    struct {
        AlertLevel       level;
        AlertDescription description;
        AlertDetails     details<0..2>;
    } Alert;

where AlertDetails is a set of bits that can be OR'ed together, and are
used only with the handshake_failure and no_certificate AlertDescriptions.

I see why details might contain 0 or 1 bytes, but not when it
might contain 2 bytes.  I also question the complication of adding a
variable-length field; not only is it messier than a fixed-field structure,
but it also requires more data to be transmitted on the wire (since
the length must be sent).

Instead, I propose that the Alert structure contain only the Level and
Description fields, but that the details be incorporated into the
description codes.  It isn't obvious that anything is gained by being
able to OR multiple detail codes - after all a fatal error is a fatal
error, and one reason is sufficient:

    enum {
        close_notify(0),
        unexpected_message(10),
        bad_record_mac(20),
        decompression_failure(30),
        cipher_mismatch(40), hash_mismatch(41), exchange_mismatch(42),
           signature_mismatch(43), authentication_mismatch(44),
           illegal_parameter(45),
        bad_certificate(61), unsupported_certificate(62),
           certificate_revoked(63), certificate_expired(64),
           certificate_unknown(65), certificate_mismatch(66),
           certifier_mismatch(67), combination_mismatch(68),
        (255)
    } AlertDescription;


>
> (6) Password authentication (particularly for clients) is extremely
> desirable.  Right now, it has to be done at an application protocol
> level (and differently for every protocol).  Having part of
> authentication occur at the SSL level and part at the application
> protocol level is not desirable.

No.  Password "authentication" is not an acceptable means of establishing
a secure connection.  It may be acceptable at the application layer,
for example to control access to particular portions of a html document
tree.  In that case, the basic authentication or digest authentication
occur at the application layer, independently of whether transport layer
security is being used.  I don't agree that that layering scheme is
"not desirable".

Normally, protocol definitions should provide mechanisms, and configuration
options should be the means of enforcing policy.  However if the STLP
is defined in such a way as to allow weak authentication, it will not
be meeting it's goals.  As stated in the SSL spec, goal number 1 is
cryptographic security.  I hope most TLS working group members agree
with that.

I strongly recommend that STLP contain no provisions for password
authentication.


> (8) MD2 and MD4 need to be phased out owing to the detection of a
> security problem.  SHA is recommended.

Agree.


> (9) There is real value in a secure datagram, particularly for
> broadcast and multicast purposes.

If UDP can be done without excessively complicating the STLP, then
fine.  I'd like to see more details, though.  Are you proposing that
handshake be done over a reliable connection and only support
application-data datagrams, or do you envision handshake / alert /
change-cipherspec over UDP?  If the former, what mechanism is used
to get the client and server to switch from TCP to UDP and back?
If the latter, how do you propose handling lost/reordered/duplicate
packets?

The ipsec work seems more suited to providing datagram security.
There is a real need, but I'm not sure STLP is the right vehicle.


As mentioned before on the TLS mail list, it would also be nice if
the STLP proposal would address:

 (11) Operation over normal port numbers, instead of special duplicate
reserved ports for each application protocol (http, smtp, nntp, telnet,
etc).

 (12) Providing sufficient information to allow firewall proxies to
authenticate the client and server and enforce access control.


> 
> 2.  Changes from SSL version 3.0
> 
> The changes made to SSL version 3.0 to produce STLP can be summarized
> as follows:
> 
> [...]
>
> * UNIX time is removed from the random challenges, to preserve sources
> of randomness.

NO!   When random numbers are used as secrets, the property of interest
is "randomness" (unpredictability or entropy).  However, both the client-
and server-generated challenges are exchanged in the clear, and once they
are known, they are no longer unpredictable.  Thus "preserving randomness"
is a non-goal for challenges.

Instead, the useful property of challenges is that they not repeat over
the lifetime of the key pair (certificate) with which they are used.
A truly random N bit number has a small but non-zero probability
of repeating any particular value.  A challenge with a deterministic
component such as time or a sequence number has a zero probability of
repeating, as long as the sequential component is reliable.  But it is
nearly impossible to guarantee that reliability, so challenges should
have both sequential and random components.



> The connection state includes the following elements:
>
> Each party maintains separate sequence numbers for transmitted and
> received messages for each connection. When a party sends or receives a
> change cipher spec message, the appropriate sequence number is set to
> zero. Sequence numbers are of type uint32 and may not exceed 2^32-1.

Since sequence numbers are not transmitted, there is no reason to
skimp on their size.  SSLv3 uses uint64 sequence numbers; I don't see
why STLP should use less even if current applications aren't likely
to overflow a uint32.  The world is full of examples of "unreachable"
limits which were later found to be inadequate.  (640K comes to mind :-)

Received on Thursday, 18 April 1996 19:41:33 UTC