Re: [TLS] No more GMT exposure in the handshake

[Kurt Roeckx <[e-mail]>]

On Sun, Jun 08, 2014 at 11:17:42AM -0700, Alex Elsayed wrote:
> Kurt Roeckx wrote:
> 
> > On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote:
> >> On 6/7/14, Daniel Kahn Gillmor <[e-mail]> wrote:
> >> > On 06/07/2014 10:56 AM, Watson Ladd wrote:
> >> >> Putting the clock time in the TLS handshake enables fingerprinting.
> >> >> It's useless cryptographically: 32 random bytes is exceedingly
> >> >> unlikely to repeat.
> >> >
> >> > There seems to be a growing consensus on this point:
> >> >
> >> >   https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime
> >> >
> >> 
> >> I've said as much to Nick and to Eric (in the context of working on
> >> tlsdate[0]) but perhaps not on this tls list:
> >> 
> >> I'd like to see servers provide 64bits of time resolution in the
> >> ServerHello and nothing but randomness in that field in the
> >> ClientHello.
> >> 
> >> The current 32bit field isn't accurate enough for replacing NTP. If we
> >> can't make the time field useful for accurate secure time exchange - I
> >> hope we'll remove all network visible distinguishers, even ones that
> >> are currently useful for totally bizarre reasons.
> > 
> > Would that be in the same format as NTP, with 32 bit for the
> > seconds and 32 bit for fractional second, and so a resolution
> > of 0.2 nano seconds?  I'm wondering what kind of accuracy you'll
> > get.
> > 
> > Anyway, how do you plan to deal with checking the status of the
> > certificate if you don't know what the current time is?
> 
> 32 bit seconds in new protocols is probably not a good idea, as 
> Linux/BSD/etc are having to deal with now - 2^32 seconds is a bit over 136 
> years, and while this use case will be unsigned (since it won't need to 
> represent pre-epoch values, which cut time_t down to ~68 years) you're still 
> going to run into something semantically identical to the Y2K38 problem. 
> When that happens depends on what you pick as your epoch.

Please note that NTP also uses the 32 bit for seconds, but has
a concept of era's.  You basicly need to know that it's not 136
years ago or in the future.


Kurt