Re: [TLS] Avoiding Trial Decryption (for 0-RTT)

"Kaduk, Ben" <bkaduk@akamai.com> Mon, 04 April 2016 14:44 UTC

Return-Path: <bkaduk@akamai.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 6881912D6F9 for <tls@ietfa.amsl.com>; Mon, 4 Apr 2016 07:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.731
X-Spam-Level:
X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 v7O8i0pvg8TI for <tls@ietfa.amsl.com>; Mon, 4 Apr 2016 07:44:51 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BB69812D55E for <tls@ietf.org>; Mon, 4 Apr 2016 07:44:51 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0CC8016D13B; Mon, 4 Apr 2016 14:44:51 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id E0D2216CEB2; Mon, 4 Apr 2016 14:44:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459781090; bh=YvEfqxkqA65UG2SyBQt9h9iwFul1U63m0kmCrELgxZ8=; l=2870; h=From:To:Date:References:In-Reply-To:From; b=MkIP/tz1j8CHJvSCnIb1nRwovqm3W0vcEovDrkE5GQrghA43js2K4kOhEuXBOVzVi 7/UTSFJmShYCVVi0ofpkaa3ugZAqVlXP26G0E3CKY6m+t7IxioTQYBEOBlfSmOOjXD wFmpvA2yNfvb5fV6Z1AzG4d087tHAeeACV1Q0sqI=
Received: from email.msg.corp.akamai.com (um-cas.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DDC131E07C; Mon, 4 Apr 2016 14:44:50 +0000 (GMT)
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Apr 2016 09:44:50 -0500
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1130.005; Mon, 4 Apr 2016 07:44:50 -0700
From: "Kaduk, Ben" <bkaduk@akamai.com>
To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Avoiding Trial Decryption (for 0-RTT)
Thread-Index: AQHRjQm8JFlri5PmdkiUvkgiHg1xY596CIoA
Date: Mon, 04 Apr 2016 14:44:50 +0000
Message-ID: <EAE13973-4E9A-42B9-8953-D2298AEDCB9C@akamai.com>
References: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr>
In-Reply-To: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.47.14]
Content-Type: text/plain; charset="utf-8"
Content-ID: <569F3FC98904DF468537D33696F2EBF0@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CH-krdwJAc0qxLz29MPoL4N5GDQ>
Subject: Re: [TLS] Avoiding Trial Decryption (for 0-RTT)
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: Mon, 04 Apr 2016 14:44:53 -0000

On 4/2/16, 14:53, "Karthik Bhargavan" <karthikeyan.bhargavan@inria.fr> wrote:

>
>Here is a proposal that would avoid trial decryption.
>When the client sends 0-RTT application data, it currently
>ends this flight of messages with an encrypted end_of_early data warning alert.
>How about: if the server rejects trial decryption, the client
>must then send an *unencrypted* end_of_early_data warning alert before
>continuing with 1-RTT handshake data.
>The server could then easily discard all records until it sees this warning alert.
>
>The main disadvantage of this approach seems to be that it reveals to the adversary
>the point at which the 0-RTT application data ends (if this is sensitive information.)
>However, note that if the length of 0-RTT data was sensitive, an attacker
>could probably already obtain it by delaying the server flight.
>
>Does anyone see other practical or security disadvantages to using this alert?

I tried to think of ways that a misbehaving client (or attacker) could cause a server relying on the unencrypted alert to consume resources and sit around waiting for a long time, but it seems like the unencrypted alert is strictly better than trial decryption in that regard (since the server doesn't have to burn CPU on decryption).  So, it seems that revealing the length of the 0-RTT data is the main disadvantage, but as Ilari notes, there are likely to be other channels that would leak that boundary in many cases.

Using the unencrypted alert does also provide a clear indication that the client/server failed to exchange 0-RTT data; for a PSK mode with a cache of 0-RTT sessions this could provide a window into the validity periods used by the two parties or as a signal that a finite-sized cache is full and ejecting old entries.  Perhaps an attacker could use that signal to determine the rate of some other sort of attack that requires getting a session evicted from the cache, but the need for such a signal seems pretty hypothetical, given that an attacker can already claim to be as many different clients as it wants.

-Ben