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

[Jacob Appelbaum <[e-mail]>]

On 6/8/14, Viktor Dukhovni <[e-mail]> wrote:
> On Sun, Jun 08, 2014 at 03:10:46PM +0000, Jacob Appelbaum wrote:
>
>> That sounds fine to me, sure. I admit, I haven't put a lot of thought
>> into the format because it seems that most of the momentum is in
>> removing anything meaningful from that field.
>
> A good thing.  If the client wants a server time-stamp, it can ask
> for it via an extension.

What extension provides a time-stamp? I'd love to see a 64bit time
stamp extension but I wasn't aware of such a thing. Is there such a
thing or was that a different spec feature request?

>
>> In any case, having 64bits of timing information from a server would
>> allow for a parasitic network time protocol that is as accurate as NTP
>> to be built on top of TLS. I haven't checked but I believe Google
>> still uses this to set clocks on ChromeOS.
>
> "As accurate as NTP" is a bold claim.  NTP "accuracy" (as opposed
> to precision which is a different beast entirely) comes from using
> multiple sourcs a PLL to estimate round-trip delay and smooth out
> noise, and when possible multiple sources, ...

Sure, I understand how NTP (and SNTP and TLS) works. That is something
that could be done with TLS and probably very easily with tlsdate.
Using a phase locked loop isn't something that exclusively functions
over UDP. In any case, I mean accuracy of detecting false tickers,
ensuring hostile networks aren't able to tamper with results (only
delaying or dropping them), as well as providing the precision
provided by a given NTP server. The precision is possible if the TLS
protocol is modified to provide the right data. At the moment, the
best we can get as an IETF compliant trick is 32bits (of seconds since
1970).

>
> NTP runs over UDP which is less likely to be delayed, re-transmitted, ...

I was told that part of why ChromeOS uses tlsdate is because UDP is
often delayed, dropped, and sometimes outright blocked. Also, NTP
punches a hole in a lot of firewalls that is hilariously dangerous for
some NTP implementations.

>
> Attaining NTP "accuracy" over TLS, seems rather implausible.
>

I think "over" TLS is a weird statement. Have you seen how tlsdate
works in practice?

( I often joke that tlsdate is stratum 11 but few people are fans of
Spinal Tap these days. )

All the best,
Jacob