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

David Benjamin <davidben@chromium.org> Wed, 29 June 2016 20:51 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213C412D7A1 for <tls@ietfa.amsl.com>; Wed, 29 Jun 2016 13:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBHrfz6GR8ch for <tls@ietfa.amsl.com>; Wed, 29 Jun 2016 13:51:16 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CFD12D7AF for <tls@ietf.org>; Wed, 29 Jun 2016 13:51:14 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id h190so53611087ith.1 for <tls@ietf.org>; Wed, 29 Jun 2016 13:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; 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; d=1e100.net; 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 10.36.101.74 with SMTP id u71mr12041453itb.92.1467233474069; Wed, 29 Jun 2016 13:51:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <CABcZeBO2Se4EVQMc_AisBUkBHNCO8t3YQWwQhRnw2TwhBjxcPA@mail.gmail.com> <CAF8qwaBPoKS1CSV49N2fWmYq6NnXTB5qo6QJV88xzatQABCPsg@mail.gmail.com> <CABcZeBPENSap9YOFE2E=N6cSNcvGrJGkqZM4qMHMFbvYFXkZfA@mail.gmail.com>
In-Reply-To: <CABcZeBPENSap9YOFE2E=N6cSNcvGrJGkqZM4qMHMFbvYFXkZfA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 29 Jun 2016 20:51:04 +0000
Message-ID: <CAF8qwaDCvY-Ozp9ub83u0wSWxZavEWL8-NLuakuMtoH-9odXYQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a1145bcf206c08d053670ea2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i1vovjUsxYvMI9ghOsb2OYtsFL0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 20:51:19 -0000

On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla <ekr@rtfm.com> wrote:

> On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <davidben@chromium.org>
> wrote:
>
>> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <ekr@rtfm.com> 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.

https://github.com/tlswg/tls13-spec/pull/508

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.)

David


>
>
>>
>>> -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 <davidben@chromium.org>
>>> 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] https://github.com/ioerror/tlsdate
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>
>>>