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

[Alex Elsayed <[e-mail]>]

Kurt Roeckx wrote:

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

Yes, but TLS does not, hence my saying "in new protocols" (or new versions 
of existing protocols) - and in a very real sense, NTP's 'era' _is_ an 
extension of the time value beyond 32 bits; just in a way that splits it up 
somewhat strangely when we could just use a 64-bit value and thus handle it 
the same way as the operating systems we'd be using it on (64-bit seconds, 
32-bit nanoseconds).