RE: Merged Transport Layer Protocol Development

I am resending this email with apologies, and ">" attributions
>Some miscellaneous responses to David Kemp's (generally interesting and
>appreciated) comments (I'll be responding separately on the specific
>subject of password authentication): 
>>> (8) MD2 and MD4 need to be phased out owing to the detection of a
>>> security problem.  SHA is recommended.
>I should point out that MD2 and MD4 appear nowhere (as far as I can
>tell) in either SSL v3.0, PCT (v1 or v2), or the STLP working document.
>A more interesting question is whether MD5 should be phased out as
>well.  I'd be interested to hear opinions on the subject.
>>> (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
>The new PPTP protocol for tunnelling PPP over the Internet specifies a
>TCP channel for control messages and IP for bulk data transmission. 
>I'm not familiar with how they specify managing the two channels
>separately, but they presumably have something in mind.
>>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,
>> (12) Providing sufficient information to allow firewall proxies to
>>authenticate the client and server and enforce access control.
>The PCT v2 spec includes a proposal for an "escrow" solution; proxies
>are provided with the decryption keys for every connection, for
>whatever checking purposes they have in mind.  Not being too familiar
>with firewalls, I'd be interested in seeing other proposals as well.
>>> 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
>>and server-generated challenges are exchanged in the clear, and once
>>are known, they are no longer unpredictable.  Thus "preserving
>>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.
>UNIX time was not removed so that challenges would be more random, but
>rather to preserve available randomness resources.  UNIX time on a
>machine may reasonably be expected to contain, say, 3 bits of entropy,
>if not sampled too often.  This may not sound like much, but when
>you're trying to harvest entropy from a PC for psuedorandom generator
>seeding, you need every bit you can scrounge.  Publicizing this value
>on a regular basis takes away its value as a contributor to this
>process.  On the other hand, given the ease (and frequency) with which
>time is reset on many machines, its value as a source of pure
>non-repeatability for challenges (as opposed to randomness) is, in my
>view, negligible.
>>> 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
>If a key is used long enough for a 32-bit sequence number to wrap, then
>it should be discarded and a new one renegotiated.  This point is made
>explicitly in the PCT specs.
>				Daniel Simon
>				Cryptographer, Microsoft Corp.

Received on Wednesday, 24 April 1996 15:53:24 UTC