[TLS] Avoiding Trial Decryption (for 0-RTT)
Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> Sat, 02 April 2016 18:01 UTC
Return-Path: <Karthikeyan.Bhargavan@inria.fr>
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 8457412D579 for <tls@ietfa.amsl.com>; Sat, 2 Apr 2016 11:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no
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 H_EIuAW8fGc3 for <tls@ietfa.amsl.com>; Sat, 2 Apr 2016 11:01:43 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A8612D577 for <tls@ietf.org>; Sat, 2 Apr 2016 10:53:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,432,1454972400"; d="scan'208";a="172223011"
Received: from aclermont-ferrand-653-1-122-31.w86-207.abo.wanadoo.fr (HELO [192.168.1.40]) ([86.207.37.31]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Apr 2016 19:53:19 +0200
From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr>
Date: Sat, 02 Apr 2016 19:53:16 +0200
To: tls@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0mwIro9e2yFgOjjaLxTYGR53qo4>
Subject: [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: Sat, 02 Apr 2016 18:01:44 -0000
TLS 1.3 0-RTT introduces an “optimistic” mode where the client encrypts data that the server can then accept or reject. In the case when the server rejects 0-RTT, the server is left in a somewhat ugly state where it will receive, in sequence: (a) encrypted 0-RTT handshake data (that it needs to throw away) (b) encrypted 0-RTT application data (that it needs to throw away) (c) encrypted 1-RTT handshake data (that it needs to process) Since we have removed content types from the record headers of encrypted messages, these 3 flights of messages look the same. So, the current draft requires the server to “trial decrypt” each message with the 1-RTT Handshake keys, in order to detect where (c) begins, and to discard packets that do not decrypt correctly. The situation can be even worse. Suppose the client sends a ClientHello and 0-RTT data, the server responds with a HelloRetryRequest, and now the client sends a new ClientHello and new 0-RTT data. In this case, we have (a), (b), (a), (b), (c); that is, the server needs to skip 4 flights of messages by trial decryption before getting to the 1-RTT handshake data. This seems inefficient and inelegant, and it may open up a new attack vector where an attacker may sent many messages and get the server to decrypt them under the same key (and same IV, etc). In other modes of TLS, a single decryption failure would close the connection, so this mode of attack is new and we may need to take care. 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? Best regards, Karthik
- [TLS] Avoiding Trial Decryption (for 0-RTT) Karthik Bhargavan
- Re: [TLS] Avoiding Trial Decryption (for 0-RTT) Ilari Liusvaara
- Re: [TLS] Avoiding Trial Decryption (for 0-RTT) Kaduk, Ben