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

Eric Rescorla <ekr@rtfm.com> Wed, 01 June 2016 22:57 UTC

Return-Path: <ekr@rtfm.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 6CE0012D0CE for <tls@ietfa.amsl.com>; Wed, 1 Jun 2016 15:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 lOE_BLuWPVF7 for <tls@ietfa.amsl.com>; Wed, 1 Jun 2016 15:57:22 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 0E12312D0C7 for <tls@ietf.org>; Wed, 1 Jun 2016 15:57:22 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id c127so33450966ywb.1 for <tls@ietf.org>; Wed, 01 Jun 2016 15:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q/vHm898afUBJjzjwd5wwxb7Z4LLiw9gTglrr6yULT8=; b=A8QqYa0+eJl11Mys9qRd3YNAE694VjB/qDEB+WA7Keg+RYFWcHojvj83QTqDJMimRy txV/M7DWtDmIM0iBHD/vCudMA0/v+NhEJt87TQm5DaplLxrMcqFY9IDPCL+zm4oHj9MF gUE4ny2ezxA/pJXyxXZy3q5H31TYwHis3q5uQ6EzDAqHF48d6rOyJxYyLR3jA2eg11ec 4AVbAu0thCuF3GHYue2zJ8X+lQFOLeYsx+QprGsnybcatlzfKX0DoTflwy8qGE5o5W50 LgSRoterGosVRfSxXTvww8pFP3N5FfvezhkAWSukiObUupotLXce1UmTVnM7c8/7bzGS LyDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q/vHm898afUBJjzjwd5wwxb7Z4LLiw9gTglrr6yULT8=; b=AbrM5FFNlp302bf2PBBdu10hv5Dlj4mfjeclo4BzbARwgjG/qWj4Whj75EwmuWnCZ7 NMs6uu5P3h1bqCHANNyKiJkLh3UcZwDpgQthLI2W48FQ3pTEbmtqZcXB83LOMvJoZ+Xe WvSuXllQxSte5ttny4tj6faf8/C5fcoEyGWzPm04XtDizhI6C1EsHdNEcvo6B1emd3pL x47VJ9D1ekmF1H+Xu8AejQodtcP38Gt6AThioTGuC+4lMHtlcmLwuEikaIuujWyYEyZw kKwhmYvJHqP0Y294TVpmpM4rGuXpeLIXeG4KpAY2vZ+OCuTRNDWL4jf62e2oZVzdGirF EUHg==
X-Gm-Message-State: ALyK8tLVFLNpDQ9no4FQH1IIytxW9+3WQIC01vxMLpbxsJ9sQDkAqVIPlXxke3MherUyX4k2P8CosBgZ5WnaRw==
X-Received: by 10.37.202.80 with SMTP id a77mr4018303ybg.74.1464821841314; Wed, 01 Jun 2016 15:57:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.230.76 with HTTP; Wed, 1 Jun 2016 15:56:41 -0700 (PDT)
In-Reply-To: <CAF8qwaBPoKS1CSV49N2fWmYq6NnXTB5qo6QJV88xzatQABCPsg@mail.gmail.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <CABcZeBO2Se4EVQMc_AisBUkBHNCO8t3YQWwQhRnw2TwhBjxcPA@mail.gmail.com> <CAF8qwaBPoKS1CSV49N2fWmYq6NnXTB5qo6QJV88xzatQABCPsg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 1 Jun 2016 15:56:41 -0700
Message-ID: <CABcZeBPENSap9YOFE2E=N6cSNcvGrJGkqZM4qMHMFbvYFXkZfA@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=94eb2c05c59e82f50b05343f6949
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fJ7vPASVNpLg48AfdvUWfEExDyo>
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, 01 Jun 2016 22:57:24 -0000

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.



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