RE: Merged Transport Layer Protocol Development

From: Dan Simon <dansimon@microsoft.com>
Date: Wed, 24 Apr 1996 10:50:29 -0700

> 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.

This complicates matters considerably for firewalls.  FTP is
"firewall-unfriendly" because it uses separate control and data
channels, both of which are TCP connections.   Allowing UDP would
make the proxy's job even more difficult.

Other than that, I don't have a philosophical objection to TLS-UDP.
But the first draft should document existing practice, which is
TCP only.  A second or separate parallel draft could discuss UDP
extensions, which would be the basis for implementations with which
people could gain operational experience.


> 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.

It's amazing how environment colors perception.  I am used to an
environment (Fortezza) with a true noise-based random number generator,
so I didn't even consider the possibility of leaking time poisoning
the random number generator for other uses where randomness really counts.

Nonetheless, as others have pointed out, time leaks out in lots of
other ways, and it's probably not a good idea to rely on it for even
3 bits of entropy.  It doesn't hurt to include it, but it won't help
if the clock is either transmitted or synchronized using NTP.

http://home.netscape.com/eng/mozilla/2.01/relnotes/windows-2.01.html says:

 "... We have significantly increased the amount of random information
  from approximately 30 bits to approximately 300 bits. Netscape has
  greatly expanded the techniques and sources used to generate these
  amounts of random information, and the fixes have been reviewed and
  validated by several weeks of intensive testing on the Internet."

Based on this statement, it would appear possible to scrounge up a
reasonable amount of entropy, even on a single-user PC, without
resorting to using the clock.

Certainly it is easy to reset the clock, but in most circumstances
people want it to bear some relation to real time (unless they
are trying to circumvent time-based software licensing restrictions :-).
In the normal environment, where a certificate may be valid for
one or more years and users aren't fooling around, the clock is
useful as a source of non-repeatability.

Philip Karlton mentioned two other reasons for including time in
the nonces - rough clock checks for certificate validity periods,
and checking for nonce freshness.  This may be useful for debugging
purposes if nothing else - ("hey dummy, your machine thinks it's
Jan 2, 2038 - no wonder it thinks my cert is expired").


>> 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.

I'm convinced.  I withdraw the objection.

Received on Thursday, 25 April 1996 14:27:36 UTC