RE: Merged Transport Layer Protocol Development

Some miscellaneous responses to David Kemp's (generally interesting and
appreciated) comments (I'll be responding separately on the specific
subject of password authentication): 

>(From dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]:)
>
>> (8) MD2 and MD4 need to be phased out owing to the detection of a
>> security problem.  SHA is recommended.
>
>Agree.

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
>packets?

>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,
>etc).
>
> (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
>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.

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.
				dansimon@microsoft.com


>
>

Received on Wednesday, 24 April 1996 13:50:45 UTC