Re: [TLS] 0.5 RTT

Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr> Thu, 25 February 2016 13:55 UTC

Return-Path: <antoine@delignat-lavaud.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ECC1ACD47 for <tls@ietfa.amsl.com>; Thu, 25 Feb 2016 05:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=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 6WthdpSNAVBZ for <tls@ietfa.amsl.com>; Thu, 25 Feb 2016 05:55:31 -0800 (PST)
Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624821ACD35 for <tls@ietf.org>; Thu, 25 Feb 2016 05:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Tv1TNsvWRwuZlAq4Nhj54w6ZvwUfu8DLixK6qIaCTwM=; b=pPTK7tmVIOHUcJhUz5enopwap+xEIZNAt9xiTInVIkRr10Vl63mPNy+0XszqO9f9gqeMwBo8BvQYBHaqggJK4IJAxWnRt7vYhg6PC6efriu2U1z4OWvwchbZ2+6mog9UNhoflqXO7MeGEON4sFsicxrC+18SNdnUdbYznQHPM/vWtFrl7tDZR7I8oFL0nbU15MQ2Z3GaC3bar4j6Ot/h7W53f/D7d16x9iD3WjxMMKozmszI88PxK7lPtCgxMbhDUzMsv3bDyECDYhWTG9bJtyYxDwWKMyrf3D2oM+vwYypVkCXwOxQ/eQziTvzWIgFOdta4nOeMoKhO2m+wBHBdwQ==;
Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from <antoine@delignat-lavaud.fr>) id 1aYwO8-0000Xm-7K ; Thu, 25 Feb 2016 14:55:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Thu, 25 Feb 2016 13:55:27 +0000
From: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
To: tls@ietf.org
Organization: Microsoft Research
In-Reply-To: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp>
References: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp>
Message-ID: <6ff7fd3f6e7b177800c388e5496387b6@maxg.info>
X-Sender: antoine@delignat-lavaud.fr
User-Agent: Roundcube Webmail/1.0.2
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AJ5iL1WNtA8v-PKdMR0-c69OlVk>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Subject: Re: [TLS] 0.5 RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 25 Feb 2016 13:55:33 -0000

Le 2016-02-25 12:29, mrex@sap.com a écrit :
> Karthikeyan Bhargavan wrote:
>> 
>> Yes Hugo, you?re right that when there is no client auth,
>> the situation is less problematic.
> 
> I'm not so sure.

QUIC gives a pretty good idea of how 0-RTT is going to be used in 
browsers: they will almost certainly send 0-RTT requests that contain 
session cookies and servers will return confidential data in 0.5-RTT 
routinely. I think it is very important to assume that this usage 
scenario is part of the core features of 1.3 that we model and analyze.

There is little doubt that 0.5-RTT will leak some bits of information 
due to replayability; nevertheless, assuming that 0.5-RTT data is always 
public and give it the same guarantees as handshake encryption is a bad 
way to deal with these problems.

Under the current key schedule, an active adversary still needs to break 
the PSK in order to decrypt 0.5-RTT data; this is a forward secrecy 
problem rather than a confidentiality one.

Even if the 0-RTT finished message is removed, the context of the 0-RTT 
data key will still include the current ClientHello, and thus, downgrade 
in the style of Logjam+False Start requires PSK compromise as well.

Concerning agility, a simple strategy is to pre-negotiate 0-RTT 
handshake parameters (including ciphersuite) when the PSK is established 
(i.e. extend the NewSessionTicket message).

Best,

Antoine