Re: [TLS] [perpass] Let's remove gmt_unix_time from TLS

[Stephen Farrell <[e-mail]>]

Hi Nick, Martin,

On 09/12/2013 04:51 AM, Nick Mathewson wrote:
> On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex <[e-mail]> wrote:
>> Nick Mathewson wrote:
>>> ====
>>> SYNOPSIS:
>>>
>>> In TLS as currently specified, clients and servers each send their
>>> current view of "the time" in the clear as part of their handshake.
>>> This provides a fingerprint that can track users in spite of other
>>> attempts to make them untrackable.  I propose several ways to stop
>>> doing sending this cleartext timestamp; some trivial and some more
>>> complex.
>>
>> I would really appreciate a different approach to the underlying
>> issue, and less throwing of smoke grenades here.
> 
> I assume good faith on your part; please do the favor of assuming good
> faith on mine.

I think its fair to say that Martin is not renowned for
taking a laid-back zen-like approach when making his
almost-always-good technical contributions:-)

But I didn't see him questioning good faith, I interpret
him as asking (forcefully:-) why this change is worth
doing.

(And that's a common pattern actually: someone says "if we
do X that'll make privacy a bit better" and someone else
says "but there are so many other ways to leak private
info, why bother just doing X?")

>> If you're worried about being slightly "distinguishable" from some
>> other clients, then there are a lot more reliable identifiers available
>> in the average TLS handshake, so claiming that sending the actual local
>> time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting
>> issue and sending random will solve the fingerprinting issue, is
>> bordering on lame for >99% of the clients.
> 
> Indeed, I never said this was a "severe" issue, or that it was the
> only issue you need to solve to solve fingerprinting.  I said: "This
> provides a fingerprint that can track users in spite of other attempts
> to make them untrackable."
> 
> I know that reading perpass, one expects proposals to fundamentally
> transform the Internet to make it more secure.  

Well, boiling oceans is definitely not the intent of this list.
My guess is that overbroad proposals will get the (lack of)
attention they deserve and will wither on the vine.

> This is not such a
> fundamental transformation. This is a little simple change to fix a
> little simple little problem.

I agree. And seems like a worthwhile one too. BTW, since
the TLS list discussion is up and running, I don't think
there's a need to cc perpass more for this. It was a good
idea to bring it here, but I suspect for this one, we can
let the TLS wg fire ahead and get someone to write up an
I-D if one is needed for this. (My guess is it'd be useful
to have a nice short RFC that updates the relevant bit of
5246 and says why.)

> Of such simple little problems, client linkability is made.
> 
>> Most of the time, repeated requests of the same TLS client can be
>> identified by the network connection having the same client IP address,
>> the TLS session proposed for resumption in ClientHello.session_id
>> or maybe someone still using TLS session tickets (rfc5077).
> 
>> So rather than pointing to ClientHello.Random.gmt_unix_time as a
>> and claiming there would be a simple fix, one will likely have to
>> create and go through a long list of issues to determine which
>> features facilitate fingerprinting and tracking (cipher suites
>> and many TLS extensions (TLS caching extension, signature algorithms,
>> Next protocol negotiation, supported elliptic curves, etc.) may
>> all help in distinguishing clients, and would also have to be
>> taken care of.
> 
> That's all true; disabling gmt_unix_time is by no means sufficient to
> make multiple TLS clients look the same on the wire, or to prevent an
> observer distinguishing TLS instances.
> 
> In Tor's case, we mitigate this by disabling some TLS features,
> specifying required values for others, rotating some identifiers more
> frequently than most implementations, and shipping all of our clients
> with the same crypto libraries.  Most of the fingerprinting issues in
> TLS can be ameliorated, for a single application, by defining a
> profile that all of that application's users should share.

I think that'd be a fine thing to document (and worthy of a
separate thread on the perpass list). Any chance we could get
that done? (Where "that" == document the implementation steps
to reduce fingerprinting opportunities as outlined above.)
I think it'd be really useful for folks doing other protocol
work to have an example of how its been done for Tor so they
could copy some of the relevant techniques when developing
other protocols. Ping me offlist if you'd like some help with
writing it up as an I-D and I can try find someone to help,
or if you've the energy just write it up and shoot it out
and I can help figure out how best to get it turned into an
RFC. If its already written up elsewhere then a pointer would
be good regardless.

Cheers,
S.

> 
> My issue here right now that, even *after* taking all these
> precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
> doesn't make it optional.  Come heck or high water, Tor is going to
> stop sending gmt_unix_time unless we find a really excellent reason to
> send it.  We'd like to replace it with the best alternative we can. I
> sent all the alternatives I could think of, because:
> 
>   1) I would like future versions of the TLS RFC to not require gmt_unix_time.
>   2) I would like to know whether there's a truly legit reason to send
> gmt_unx_time.
>   3) I would like to know the best thing to do instead of gmt_unix_time.
> 
> (The IP address issue is important too, but not overriding here. The
> issue here is that even after a client has changed its IP addresses
> either through moving around the network or going behind a NAT or VPN
> or by using an IP anonymization service, this fingerprint remains.)
>