Subject: [TLS] Consensus Call on Removing GMT from the Handshake

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 13 Jun 2014 23:11:48 +0000

There appears to be significant support for the removal of GMT from the client
and server random values in TLS. The chairs would like to ask two questions:

- Should we remove the GMT values from the client and server values in TLS 1.3?

- Should we remove the GMT fields from the current versions of TLS and adopt
draft-mathewson-no-gmtunixtime-00 or something similar?

If you have an opinion on this topic, please reply to the TLS list with your reasons by Friday, June 20

Joe
(for the chairs)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jun 2014 17:16:53 -0700

> - Should we remove the GMT values from the client and server values in TLS 1.3?

I'd prefer to see it removed.

> draft-mathewson-no-gmtunixtime-00 or something similar?

I think that this statement:

   ... TLS implementors
   MUST by default set the entire value the ClientHello.Random and
   ServerHello.Random fields, including gmt_unix_time, to a
   cryptographically random sequence.

Is enough.  The rationale is a little overblown.

That should help expose more of the RNG state ;)

---

From: Adam Langley <[email-masked]>
Date: Fri, 13 Jun 2014 17:28:52 -0700

> - Should we remove the GMT values from the client and server values in TLS 1.3?

Yes, in the same way as below...

> draft-mathewson-no-gmtunixtime-00 or something similar?

Yes, at the SHOULD level. For servers we have some clients that take a
clock-sync signal from the GMT time and we wouldn't immediately want
to break them.

For clients, there is basically no value and it leaks a fingerprint.
Additionally, this would be reflecting reality because implementations
are already doing this.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 14 Jun 2014 13:31:14 +0000

> - Should we remove the GMT values from the client and server values in TLS

I would request that the language in 1.3 be MUST for clients to avoid
client fingerprinting by a passive or active adversary. For servers, I
would request that they servers SHOULD make it random. I would also
request that for 1.3 that it isn't a requirement (MUST) to make it
random.

> draft-mathewson-no-gmtunixtime-00 or something similar?

Yes. I would request that the language be SHOULD for servers and MUST
for clients.

As a general comment, I also think it makes sense to hash the output
with something cryptographically secure such as SHA-256. I think it is
a bad sign to expose random bytes from the RNG to the wire. This kind
of exposure is (partially) what allows exploitation of the
DUAL_EC_DRBG backdoor. We probably want to stop that kind of
information leakage as a matter of defense in depth.

> reasons by Friday, June 20

The above will help users of various software such as tlsdate to transition.

All the best,
Jacob

---

From: "Michael Staubermann" <[email-masked]>
Date: Sat, 14 Jun 2014 22:54:04 +0200

My +1 for all requests.

-mst

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Jacob Appelbaum
> Sent: Saturday, June 14, 2014 3:31 PM
> To: Joseph Salowey (jsalowey)
> Cc: <[email-masked]>
> Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake
> 
> > There appears to be significant support for the removal of GMT from
> > the client and server random values in TLS. The chairs would like to
> > ask two
> > questions:
> >
> > - Should we remove the GMT values from the client and server values
> in
> > TLS 1.3?
> >
> 
> > - Should we remove the GMT fields from the current versions of TLS
> and
> > adopt draft-mathewson-no-gmtunixtime-00 or something similar?
> 
> of exposure is (partially) what allows exploitation of the DUAL_EC_DRBG
> backdoor. We probably want to stop that kind of information leakage as
> a matter of defense in depth.
> 
> >
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Sun, 15 Jun 2014 10:45:36 -0400

> - Should we remove the GMT values from the client and server values in TLS 1.3?

Yes, these should be allowed to be any values, so that GMT values are still allowed.

> draft-mathewson-no-gmtunixtime-00 or something similar?

Yes, as above.

Russ

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 15 Jun 2014 17:52:34 -0700 (PDT)

On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote:
>> - Should we remove the GMT values from the client and server values in
>> TLS
>> 1.3?
>>
>

  I see no value in retaining the GMT value in the server random. Making
it optional requires some justification. Care to share it?

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 15 Jun 2014 22:52:58 -0300

> it optional requires some justification. Care to share it?

Tails currently uses the gmt time from servers to figure out what time
it is. Making it optional lets them ween off.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 16 Jun 2014 00:50:40 -0700 (PDT)

On Sun, June 15, 2014 6:52 pm, Watson Ladd wrote:
>>>> the
>>>> client

  I don't know what "Tails" is but deciding what time it is based on the
value of a field that you have no guarantee that you'll find in a received
packet sounds like a really bad idea. And since this is a consensus call
for removing the GMT value from random in a new version of TLS then
"Tails" can figure out some other way to determine time when it
negotiates this new version.There is no weening possible or needed.

  Dan.

---

From: Robert Ransom <[email-masked]>
Date: Mon, 16 Jun 2014 01:28:28 -0700

> negotiates this new version.There is no weening possible or needed.

‘Tails’ (<https://tails.boum.org/>) is a live CD which, roughly,
routes all of a user's traffic through Tor.  I don't remember whether
it still uses ‘tlsdate’ (they put considerable effort into switching
to learning the system time from Tor's directory documents), but it
used a small set of servers for tlsdate and it did enough sanity
checking on tlsdate's results that it wouldn't have been confused by
random values in that protocol field.

The more important (widely deployed) use of tlsdate is in Google's
ChromeOS, which is probably why Adam Langley wants to not immediately
turn off that timestamp field on Google's servers.  Since Google
controls both the client software and the servers used for tlsdate in
ChromeOS, their use of tlsdate should be completely safe.

Robert Ransom

---

From: Nick Mathewson <[email-masked]>
Date: Mon, 16 Jun 2014 10:25:16 -0400

On Mon, Jun 16, 2014 at 4:28 AM, Robert Ransom <[email-masked]> wrote:
 [...]
> ChromeOS, their use of tlsdate should be completely safe.

For what it's worth, I believe that recent versions of tlsdate also
support learning the current time from an HTTPS "Date:" header, so
there's a plausible upgrade path there.

(Anybody who is interested in security and time should have a look
over at the NTP working group.  If I'm not mistaken, they've been
discussing an open draft that tries to improve the state of security
in NTP.)

cheers,
-- 
Nick Mathewson

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 16 Jun 2014 12:10:46 -0700 (PDT)

On Mon, June 16, 2014 1:28 am, Robert Ransom wrote:
> 'Tails' (<https://tails.boum.org/>) is a live CD which, roughly,
> it still uses 'tlsdate' (they put considerable effort into switching

  Very cool!

> ChromeOS, their use of tlsdate should be completely safe.

  In both of these cases, the client seems to know when it's talking to
a like instance of TLS-- either a Tails client connecting to a Tor server
or a ChromeOS client connecting to a Google server-- so this can be
supported proprietarily. Think of "random" as a covert channel and
tlsdate as the data to transfer through it.

  Neither of these are a really justification for making it optional in
the standard to include GMT in the server random.

  Dan.

---

From: Jacob Appelbaum <[email-masked]>
Date: Mon, 16 Jun 2014 23:30:28 +0000

> tlsdate as the data to transfer through it.

Previously, it was a standard way to securely fetch time - downgrading
it to something that is far from a covert channel seems less than
ideal. :)

> the standard to include GMT in the server random.

The reason to make it optional is that it impacts clients in the wild
who depend on this detail in the specification. These are just a few
examples of who uses it. Such a change will affect (tens? of) millions
of users in the case of ChromeOS alone. It makes sense to allow time
to transition.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Mon, 16 Jun 2014 23:31:22 +0000

> there's a plausible upgrade path there.

Yes, that is exactly correct - it isn't clear to me if Google has
switched to this specific method of using tlsdate. Thanks again for
the patch!

> discussing an open draft that tries to improve the state of security

That sounds great - thanks for the heads up.

All the best,
Jacob