Re: [TLS] Downgrade protection, fallbacks, and server time

David Benjamin <> Wed, 01 June 2016 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C87112D573 for <>; Wed, 1 Jun 2016 15:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bYGseXhm63_3 for <>; Wed, 1 Jun 2016 15:53:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C22F12D15A for <>; Wed, 1 Jun 2016 15:53:35 -0700 (PDT)
Received: by with SMTP id i127so36802022ita.1 for <>; Wed, 01 Jun 2016 15:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xZpw9nlR3NnSRqLTJHDj/gt37tcWWMBYBylT0l0441A=; b=MH5cLz9AyqPCXF0Wk4F2nv55DeJw7IdYYZJH8SobQLF+Ct27bezEevpR2dIVGIimqX LeICuXNhpruI1ImkN3HkDkBCeBWT6aEWunjtzuX38L53y49lyzSEENvIOAkIVtBY7/A0 Kka9uu3z8uMYsXXbWhhEz78njI7JdBXNgtNgg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xZpw9nlR3NnSRqLTJHDj/gt37tcWWMBYBylT0l0441A=; b=mY7Cguq3MmhOnQBNRO9rw7tWOcOTvk0I2TERcHKsuL4rNDY/ZspCE9JUIbXgumySsh 51P3fwONN2lx6kr3XsFGniny2IPT+jXpc1cRBzO4WlEtgorIRnskhViQbkDHv7N6b+pJ B7fWO073zp7+ZZ7rsTib3B2xANePGYdVYheiyTwvYOkbUvZ9cqLOI7DRy0E4ObD5CptQ FNwKD1Rz0FTr/l4m0J9MNDVnHV69ECLkBM9yIWJY+FTRd/JJywQ7tJ0MuFA7st1wrNO4 LxXSOuniTt/S2lck28CY6BoC0h6SMASoxw9EJKWUr2Ow9awRWOuWC0/xQJcj//IerlTX 8mgQ==
X-Gm-Message-State: ALyK8tLDzFxJ78B1b82e31BcruBjG8rqJdv/I6SuWDS7S+2ur/HuSdBGbaPK3YB+7MGVm797D5aml5zglQzGYIzo
X-Received: by with SMTP id e123mr441221ith.92.1464821614428; Wed, 01 Jun 2016 15:53:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 01 Jun 2016 22:53:24 +0000
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=94eb2c006f64fd3c0e05343f5b81
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2016 22:53:38 -0000

On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <>; wrote:

> 2% is actually pretty good, but I agree that we're going to need fallback.
> I'd be fine with moving the 8 bytes to the end, but I wonder if it would
> be better to
> instead have the *client* indicate its max version and the server check.
> That would
> have the advantage that it would leave more of the server random intact.

That sounds reasonable to me. I'd probably suggest still putting it at the
end since there's no reason to risk things, but I'm not aware of anything
that uses the client timestamp. (None of the clients I maintain send it.)

> -Ekr
> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the
> server.

Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection
(otherwise the version fallback even loses that one). I only mean in terms
of mitigating the additional damage done by the fallback, not replacing the
entire mechanism.

(Although, do we actually get the stronger protection if the client accepts
plain RSA key exchange? I've never been very clear on that. Realistically,
clients will be accepting plain RSA for a long while.)


> On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <>;
> wrote:
>> In case folks hoped we could bump the ClientHello version without those
>> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
>> exists. (Maybe we should just give up on ClientHello.version and use an
>> extension? Extensions have rusted less.)
>> I picked a large list of top sites and tried connecting to them. Just
>> under 2% of them could handle a TLS 1.2 ClientHello, but not the same
>> ClientHello with the version switched to 1.3 (no other changes, so I
>> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I
>> expect if you probe any top site list, you'll very quickly find some.
>> Fortunately, the ServerHello.random trick fixes this. But it currently
>> clobbers the old server timestamp which tlsdate[1] uses for clock
>> synchronization. There really should be a less silly secure timestamping
>> protocol, but, today, tlsdate has users. Any servers which expect to be a
>> tlsdate target can't honor this MUST without tlsdate gone.
>> (FALLBACK_SCSV works fine as well, but I gather people prefer the
>> ServerHello.random one and would be unhappy having to implement both in
>> clients with a fallback because not all servers do the latter.)
>> I mentioned this before, but rather than clobbering the first 8 bytes,
>> the last 8 bytes seems as reasonable and avoids this unnecessary
>> complication to TLS 1.3 deployment. If folks agree now that the
>> fallback's resurrection is more certain, I'm happy to put together a PR.
>> David
>> [1]
>> _______________________________________________
>> TLS mailing list