- From: Phil Karlton <karlton@netscape.com>
- Date: Wed, 24 Apr 1996 19:42:10 -0700
- To: David Wagner <daw@cs.berkeley.edu>
- Cc: ietf-tls@w3.org
> 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.
The time of day is in the Random structure for SSL 3 for three reasons:
1) It reduces the probability that any particular Random will be reused.
As long as sessions are not being established (or reestablished) more
frequently than once a second, then there is a logical sequence number
as part of the structure.
2) Keeping a reasonably accurate time-of-day clock on the client's and
servers is important. For instance, typical certificates are only good
for 6 months. If the user never sets the clock on the client or server
machine, then even the checks for certificates being current will fail.
Some error checking for egregiousl bad values can be done.
3) The value of the time-of-day should be made available through the
API. For applications that need more protection from replay attacks,
there would be the ability to make sure that the nonce's are relatively
current. This may not be feasible for all applications at this point,
but we should be able to make use of this as time progresses.
28 bytes of random (or nearly random) data should be be sufficient for
establishing keys with 16 bytes of entropy. I strongly recommend that
the time not be removed from the Random structure.
PK
--
Philip L. Karlton karlton@netscape.com
Principal Curmudgeon http://home.netscape.com/people/karlton
Netscape Communications
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
- Benjamin Franklin
Received on Wednesday, 24 April 1996 22:42:15 UTC