FW: Merged Transport Layer Protocol Development

Because some members of tls-draft are not members of ietf-tls where the
following message was posted, I am forwarding this message onto the full
tls-draft alias for review.

>----------
>From: 	dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]
>Sent: 	Tuesday, April 16, 1996 9:08 AM
>To: 	ietf-tls@w3.org
>Subject: 	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 Friday, 19 April 1996 14:45:34 UTC