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

[Robert Ransom <[e-mail]>]

On 6/16/14, Dan Harkins <[e-mail]> wrote:
>
> On Sun, June 15, 2014 6:52 pm, Watson Ladd wrote:
>> On Sun, Jun 15, 2014 at 9:52 PM, Dan Harkins <[e-mail]> wrote:
>>>
>>> On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote:
>>>> On 6/13/14, Joseph Salowey (jsalowey) <[e-mail]> wrote:
>>>>> 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?
>>>>>
>>>>
>>>> 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.
>>>
>>>   I see no value in retaining the GMT value in the server random. Making
>>> 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.
>
>   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.

‘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