I have looked at this some, network appliances such as F5s Big IP use a random value instead of time.
I recall seeing some clients also do this but I don't recall which ones. Basically such a change should be safe. That said as Russ has pointed out TPSDATE uses this mechanism and though it doesn't solve a broken cryptographic subsystem it is kind of belt and suspenders approach. Ryan Hurst Chief Technology Officer GMO Globalsign twitter: @rmhrisk email: [email protected] phone: 206-650-7926 Sent from my phone, please forgive the brevity. On Sep 11, 2013, at 9:06 AM, Eric Rescorla <[email protected]> wrote: > Before we discuss mechanisms, it would be good to verify that in general > clients and servers don't become unhappy if the timestamp is radically > wrong. Has someone done measurements to verify that this is in fact > the case at a broad scale? > > -Ekr > > > > On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <[email protected]> wrote: >> I'm in favor of proposal 1, and second the considerations about it; >> essentially, a broken crypto implementation cannot be fixed by a >> timestamp. >> >> If proposal 2 (and 3) was to be implemented on a server, it would also >> make DoS easier, because a cheap ClientHello (even generated with weak >> randomness) would trigger an extra HMAC computation on the server, >> with respect to the current server load. >> >> Hence, relying on PRNG on both client and server sides looks like a >> reasonable way to go. I also don't particularly like the asymmetry >> that proposal 2 may bring: client generating randomness with HMAC, and >> servers still using the timestamp in clear. >> >> Cheers, >> Alfredo >> >> On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <[email protected]> wrote: >> > Hi, all. >> > >> > Here's something I wrote about removing a fingerprinting opportunity >> > from the current TLS protocol. I was going to just send it to the tls >> > list, but Ben Laurie suggested that I send it to the perpass list as >> > well. >> > >> > I have little standards-body experience; if this ought to turn into an >> > RFC or something, I'd be happy to write a draft if need be. >> > >> > >> > (Tor currently plans to implement this by patching OpenSSL; any >> > feedback or advice would be appreciated. The first three approaches >> > below are implemented in OpenSSL branches named "no_client_timestamp", >> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git >> > repository at https://github.com/nmathewson/openssl . We have long >> > shipped our privacy-enhanced browser with a feature like this enabled >> > through an NSS patch.) >> > >> > >> > ==== >> > 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. >> > >> > >> > ACKNOWLEDGEMENTS: >> > >> > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me >> > feedback here. >> > >> > >> > PROBLEM: >> > >> > The gmt_unix_time field in the Random field in the TLS handshake >> > provides a way for an observer to fingerprint clients. >> > >> > Despite the late date, much of the world is still not >> > synchronized to the second via an ntp-like service. This means >> > that different clients have different views of the current time, >> > which provides a fingerprint that helps to track and distinguish >> > them. This fingerprint is useful for tracking clients as they >> > move around. It can also distinguish clients using a single VPN, >> > NAT, or privacy network. (Tor's modified firefox avoids this by >> > not sending the time.) >> > >> > Worse, some implementations don't send the current time, but the >> > process time, or the computer's uptime, both of which are far >> > more distinguishing than the current time() value. >> > >> > The information fingerprint here is strong enough to uniquely >> > identify some TLS users (the ones whose clocks are hours off). >> > Even for the ones whose clocks are mostly right (within a second >> > or two), the field leaks a bit of information, and it only takes >> > so many bits to make a user unique. >> > >> > Of course, I realize that the gmt_unix_time fingerprint is not the >> > only way to track a typical client as it moves from network to >> > network, and not the only way to distinguish different clients >> > behind a NAT. >> > >> > >> > >> > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE? >> > >> > According to third-hand reports (and correct me if I'm wrong!) >> > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure >> > in cases where the PRNG was completely broken, by making a part of >> > the Random field that would definitely vary between TLS handshakes. >> > >> > I doubt that this goal is really achieved, for two reasons: >> > >> > * On modern desktop environments, it's not really so strange to >> > start two or more TLS connections within the same second. When >> > this occurs, the gmt_unix_time fails in its intended purpose of >> > preventing repeated Random values. >> > >> > * Nonwithstanding the gmt_unix_time workaround, TLS in general >> > does not withstand broken PRNGs. For one example, if an >> > implementation's PRNG is prone to repeating ClientRandom >> > values, it is probably prone to repeating those some values as >> > ephemeral Diffie-Hellman private values. >> > >> > Nevertheless, if the goal of providing unique-looking output >> > >> > >> > >> > WHY ELSE IS gmt_unix_time USED? >> > >> > The consensus among implementors I've asked seems to be that it's >> > unwise to depend on any particular value or interpretation for the >> > field. The TLS 1.2 standard, RFC 5246, says that "Clocks are not >> > required to be set correctly by the basic TLS protocol; higher-level >> > or application protocols may define additional requirements." >> > >> > Some implementations set the entire gmt_unix_time field randomly; >> > this appears not to have broken TLS on the internet. >> > >> > At least one tool (tlsdate) uses the server-side value of the >> > field as an authenticated view of the current time. >> > >> > >> > >> > PROPOSAL 1: >> > >> > Declare that implementations MAY replace gmt_unix_time either with >> > four more random bytes, or four bytes of zeroes. >> > >> > Rationale: >> > * Some implementations (like TorBrowser) are already doing this >> > in practice. >> > >> > * It's sensible and simple. Implementors are quite unlikely to >> > mess it up. >> > >> > >> > >> > PROPOSAL 2: >> > >> > Suppose that we do not accept the argument about the pointlessness >> > of gmt_unit_time that I make above, and we want to preserve the >> > security it allegedly provides. >> > >> > In that case, we can allow the following approach instead: >> > >> > Set the Random field, not to 32 bytes from your PRNG, but to the >> > HMAC-SHA256 of any high resolution timer that you have, using 32 >> > bytes from your PRNG as a key. In other words, replace this: >> > >> > Random.gmt_unix_time = time(); >> > Random.random_bytes = get_random_bytes(28) >> > >> > with this: >> > >> > now = hires_time(); // clock_gettime(), or concatenate time() >> > // with a CPU timer, or process >> > // uptime, or whatever. >> > key = get_random_bytes(32); >> > Random = hmac_sha256(key, now); >> > >> > This approach is better than the status quo on the following >> > counts: >> > >> > * It doesn't leak your view of the current time, assuming that >> > your PRNG isn't busted. >> > >> > * It actually fixes the problem that gmt_unix_time purported to >> > fix, by using a high-resolution time that's much less likely to >> > be used twice. Even if the PRNG is broken, the value is still >> > nonrepeating. >> > >> > I do not think this is not worse than the status quo: >> > >> > * It is unpredictable from an attacker's POV, assuming that the >> > PRNG works. (Because an HMAC, even of known data, with an >> > unknown random key is supposed to look random). >> > >> > >> > PROPOSAL 3 >> > >> > As a hybrid alternative, one could set part of the ClientRandom >> > field (perhaps 12 bytes or so) based on the HMAC of the time, and >> > the rest of the ClientRandom field based on the PRNG: >> > >> > N = 12 >> > >> > now = hires_time(); >> > key = get_random_bytes(32); >> > mac = hmac_sha256(key, now)[0:N]; // First N bytes. >> > rand = get_random_bytes(32 - N) >> > Random = mac ++ rand // concatenate. >> > >> > But this seems to be getting pointlessly baroque. >> > >> > >> > >> > CONSIDERATIONS: >> > >> > I'd personally suggest proposal 1 (just set the field at random) for >> > most users. Yes, it makes things a little worse if your PRNG can >> > generate repeat values... but nearly everything in cryptography >> > fails if your PRNG is broken. >> > >> > >> > We might want to apply this fix on clients only. With a few >> > exceptions (like hidden services) the server's view of the current >> > time is not sensitive. >> > >> > >> > Implementors might want to make this feature optional and >> > on-by-default, just in case some higher-level application protocol >> > really does depend on it. >> > _______________________________________________ >> > TLS mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
