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

From: Watson Ladd <[email-masked]>
Date: Sat, 7 Jun 2014 07:56:36 -0700

Dear all,

Putting the clock time in the TLS handshake enables fingerprinting.
It's useless cryptographically: 32 random bytes is exceedingly
unlikely to repeat.

Sincerely,
Watson Ladd

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 07 Jun 2014 13:26:31 -0400

> It's useless cryptographically: 32 random bytes is exceedingly

There seems to be a growing consensus on this point:

  https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime

	--dkg

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 7 Jun 2014 21:55:23 +0000

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

All the best,
Jacob

[0] https://www.github.com/ioerror/tlsdate

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Jun 2014 16:02:13 -0700

I've created a github issue

[https://github.com/tlswg/tls13-spec/issues/42]

to keep track of this.

-Ekr

On Sat, Jun 7, 2014 at 2:55 PM, Jacob Appelbaum <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 8 Jun 2014 12:17:21 +0200

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

Kurt

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 8 Jun 2014 15:10:46 +0000

> of 0.2 nano seconds?  I'm wondering what kind of accuracy you'll

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.

> certificate if you don't know what the current time is?

tlsdate has a bunch of options for that situation. I'd suggest
checking out how ChromeOS uses it as tlsdate is their default NTP-like
client for ChromeOS. It has short comings, of course.

With tlsdate, one may skip on checking the time and date constraints
for the first connection by setting some other constraints. As an
example, ensuring that the clock is moving forward while still having
assurances that an attacker must control specific cryptographic keys,
etc.

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.

I have a lot to say about tlsdate but it seems out of scope here.
Check out the code and please do help us to improve it!

All the best,
Jacob

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 8 Jun 2014 15:39:36 +0000

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

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

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

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

-- 
	Viktor.

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 8 Jun 2014 18:21:41 +0200

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

I think even getting it's precision will be hard.

But I wonder what kind of accuracy do you really want?  I think
getting an accuracy smaller than 1 second shouldn't be that hard,
but ntpd is only claiming an accuracy in the order of 0.1 seconds
in most cases and if you're lucky you get an estimated one in the
order of 1 ms.  But do most people care about 1 second?  Or even
10 seconds?  And if you do care about the accuracy, why don't you
run ntp?

Kurt

---

From: Martin Thomson <[email-masked]>
Date: Sun, 8 Jun 2014 09:41:34 -0700

> are currently useful for totally bizarre reasons.

I think that I'd prefer erasure.  But the idea of parasitically
updating time is intriguing.  I assume that you need some sort of out
of band method for determining if the server has OK time in the first
place.  I know Google have some techniques for good time sync, but
most servers have completely rubbish clocks.

---

From: Bill Frantz <[email-masked]>
Date: Sun, 8 Jun 2014 09:43:00 -0700

>certificate if you don't know what the current time is?

It seems to be a poor policy to trust time information from a 
server whose certificate you are trying to validate.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345 
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos, 
CA 95032

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 8 Jun 2014 22:19:30 +0000

> A good thing.  If the client wants a server time-stamp, it can ask

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?

> 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

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 8 Jun 2014 22:27:07 +0000

> server whose certificate you are trying to validate.

Isn't it worse to trust a network protocol without any cryptographic
assurances at all? I think so... I also tend to think the right choice
is to fix NTP but we'll almost always have this first leap of
something. I'd prefer it not to be a mere leap of faith but rather a
leap of cryptographic assertion pinned to a set of keys that I trust.

Until the time that NTP is fixed to deal with hostile networks, we've
got hundreds of thousands of SSL/TLS servers on the internet that
serve mostly accurate time.

All the best,
Jacob

---

From: Bill Frantz <[email-masked]>
Date: Sun, 8 Jun 2014 15:51:56 -0700

>serve mostly accurate time.

OK, after making a flip remark, now I need to actually think 
about the requirements. For validating certificates (only):

   Time accuracy +- 24 hours or so.

   Trust in the time source.

If I get my time from the server I'm validating, then continued 
use of expired certificates is really easy. If I get it from a 
separate NTP server,then the attack becomes harder, but someone 
controlling my network traffic still has a relatively easy 
problem. If I use almost any source of time, and verify big 
jumps from my local clock with my user, the problem becomes 
almost impossibly difficult.

BTW, I have two devices, a radio and a Raspberry Pi, which have 
internal clocks which are reset to zero at power on. These would 
be vulnerable to the first two scenarios and not able to 
implement the third scenario. Its a good thing my plans for them 
don't involve network connections.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

---

From: Alex Elsayed <[email-masked]>
Date: Sun, 08 Jun 2014 11:17:42 -0700

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

If you use it to transmit GPS time using that epoch, or UTC using the Unix 
epoch, then you will have some real problems.

The BSDs are switching wholesale to 64-bit tv_sec and 32-bit tv_nsec as I 
understand it; Linux is in the process of doing the same (but with stricter 
procedures on what's allowed to change ABI).

Similarly, you also probably want to consider exactly what time base you use 
- UTC brings in the mess of leap seconds, TAI avoids them but is subtly 
different and may surprise implementers who don't realize that.

In the end, I'd want to just chop it out - overloading TLS as a time-syncing 
protocol looks like the makings of a mess to me, since time handling is 
already quite messy.

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 9 Jun 2014 17:08:26 +0200

> 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

---

From: Alex Elsayed <[email-masked]>
Date: Mon, 09 Jun 2014 15:32:16 -0700

Kurt Roeckx wrote:

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

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