Re: Merged Transport Layer Protocol Development

David Wagner writes:
> 
> In article <199604242216.PAA07915@work.ucsd.edu>,
> Bennet Yee  <bsy@cs.ucsd.edu> wrote:
> > In message <c=US%a=_%p=msft%l=RED-92-MSG-960424195112Z-26742@tide21.microsoft.c
> > om>, Dan Simon writes:
> > > 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.
> > 
> > All modern Unix systems provide the time on the daytime port [...]
> > Furthermore, many machines use the Network Time Protocol [...]
> 
> Good points, all of them.
> 
> As Ian Goldberg & I have pointed out, there are still more ways the time
> can leak.  For instance, Message-IDs often contain the time of day.  (And
> you can usually force a targeted Unix machine to send you a Message-ID by
> sending it a message which will bounce.)
> 
> This is pointed out in e.g.
> 	http://www.ddj.com/ddj/1996/1996.01/wagner.htm
> 
> I think the clock skew between you & a target machine is not too hard to
> recover very accurately.  I think it's dangerous to rely on there being
> any significant entropy in the time of day.


On the other hand, it doesn't hurt to use it, if you already
have enough unguessable truly random bits.  Adding guessable
bits to a series of unguessable ones doesn't make them any
more guessable.  But since it doesn't add anything, it
shouldn't be there.

Rather than arguing about including the (useless) time value in
the {client,server}-random value, should we specify how random and
unguessable the bits that go into them should be?  That's
what we really care about, rather than the method(s)
that might be used to get those random bits.  Those methods
are varied and are liable to be non-portable.

However specifying the right amount of unguessable randomness might
become distracting from the main purpose of coming up with a TLS spec.
Perhaps we can just say "pick good random numbers, see RFC 1750".


-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Wednesday, 24 April 1996 22:50:02 UTC