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

David Benjamin <> Wed, 29 June 2016 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 213C412D7A1 for <>; Wed, 29 Jun 2016 13:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Status: No, score=-4.125 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_LOW=-0.7, 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 mBHrfz6GR8ch for <>; Wed, 29 Jun 2016 13:51:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2CFD12D7AF for <>; Wed, 29 Jun 2016 13:51:14 -0700 (PDT)
Received: by with SMTP id h190so53611087ith.1 for <>; Wed, 29 Jun 2016 13:51:14 -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=b8mPak+CVKYhrds9hSJxtLufE6d7GZJvtwZIwEZz8QI=; b=YPE6+nz0sDB6rc8UmKheZkMycmbc1JAnnMuXYc8P4M4F1rpFqvV0kGrRmWAc66PBB8 p3+ss30GGaF9DkJ4CmaDT9FL/bahPm4hpj5KhvVCL4abty12F651/0kOgZbrPRQfUQT9 yyO8Rz7vkblXPQpozmRKaWCSlgTx3wRkuVK0w=
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=b8mPak+CVKYhrds9hSJxtLufE6d7GZJvtwZIwEZz8QI=; b=FayywxLLSeyGKmDIpOQr99cvViTp8fqomFYA86BfHULJKe7yl8uzZKp6wNK7IShFsc MQMHSPWqEz5bd9JvNGySHhksqGMu/WgDG2oTLMyH7evKYspWLJ5OLj2WyKI8cAIEXa2D H7Evo7CbZFVjpyxKp4+tN3Gn2vOvwffLItFdVo34LvK1dTiBPQMxLmY+d/bT/SgK0EDr 4JH7qU0q7SwMgwPGGgU3bTI+uK28l3NQVr6h6oarCz0zu7ZUHYd5MGLz0IHtaMrYujl+ W8oBgNvbRq1qXgY12eAExWHRO9CkX1in54akxnqUlSqPduimGVQRhj1RGMr18ncmEwEW QYvA==
X-Gm-Message-State: ALyK8tLbuOoHvH/7lUx3MDLJt1VS8Vd8dtNRIG4VK3vFwGXLUgBkupLIibpgW06pvjE3G6DU7BPRB2GBwOIi6wC7
X-Received: by with SMTP id u71mr12041453itb.92.1467233474069; Wed, 29 Jun 2016 13:51:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 29 Jun 2016 20:51:04 +0000
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a1145bcf206c08d053670ea2b"
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, 29 Jun 2016 20:51:19 -0000

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

> On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <>
> wrote:
>> 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.)
> Putting it at the end of the client gives the client options, so that
> would be fine.

To get this thread back on the original point, I put together a PR here for
the minimal change which just moves it to the end of server_random. This
would be sufficient to fix the problem which prevents today's 1.2 servers
from implementing 1.3.

I don't particular care whether it's moved to the client or not. If you
think that's better, I'm happy to change it or defer to a different PR. (I
wasn't sure exactly what construction you were thinking for the
client_random version.)


>>> -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.)
> Yes, that's correct. I don't believe we have a good plan for plain RSA.
> -Ekr
>> David
>>> 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