Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

Dave Garrett <davemgarrett@gmail.com> Thu, 24 December 2015 22:01 UTC

Return-Path: <davemgarrett@gmail.com>
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 D15731A6F20 for <tls@ietfa.amsl.com>; Thu, 24 Dec 2015 14:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 xHXFDo4LugGc for <tls@ietfa.amsl.com>; Thu, 24 Dec 2015 14:01:51 -0800 (PST)
Received: from mail-qg0-x242.google.com (mail-qg0-x242.google.com [IPv6:2607:f8b0:400d:c04::242]) (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 5EB6F1A6F1F for <tls@ietf.org>; Thu, 24 Dec 2015 14:01:51 -0800 (PST)
Received: by mail-qg0-x242.google.com with SMTP id b35so4217234qge.2 for <tls@ietf.org>; Thu, 24 Dec 2015 14:01:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=fAZJwauc/Dz4LEus1IGX7jZTZyGj18U/oRyvanfkOM0=; b=fDZCadcc1cVUVFnT+TW0pKgZzkOBv+koCxJMhB77TvNofT3HNfvkm+CKuEvGN+pmCk Ey/HAJmXauYM44P8nRKluPmjtqk61kY8TOyGOdcLOfuFyWhaSTTUJ0atny37N7zNv8yN O1NIDG+T8+Ug6B60yI4Olac9KE3mG0YsCaQInIN/whcenPufSG+8F5k7w6suC3OI+iQ8 OjuMzbBWvRt51M3b+vuVhL+s0u6JZAXpR4xGixbznnmgQiXE456bWCIMS+w4xbpMJ2Zk 1Ik+5Wn3VlEWwZ6Ll+ouza1hLN7Iz6bPZm7DGH1J6iwiVeaYikmxwKEPIHUYniA25rpG MHhg==
X-Received: by 10.140.168.85 with SMTP id o82mr43739431qho.8.1450994510561; Thu, 24 Dec 2015 14:01:50 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id u67sm3117391qku.1.2015.12.24.14.01.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 24 Dec 2015 14:01:50 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 24 Dec 2015 17:01:48 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <201512241626.41884.davemgarrett@gmail.com> <CABcZeBP4THDJn5djaZpbUcVTLJgugb=h+7Si0k4JeM-2ow1y6w@mail.gmail.com>
In-Reply-To: <CABcZeBP4THDJn5djaZpbUcVTLJgugb=h+7Si0k4JeM-2ow1y6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201512241701.49373.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/bHAH9tWQOxCgj_SgawXi3BZHiMg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
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, 24 Dec 2015 22:01:53 -0000

On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > Do we have anything that protects against an intermediary stripping 0RTT
> > messages from a handshake to force a fallback?
> 
> Yes:
> 1. The EarlyDataIndication tells the server that some 0-RTT messages are
> coming.
> 2. The Finished in the 0-RTT flight covers the entire handshake flight,
> thus preventing
> tampering with those messages.
> 3. The server's Finished covers the ClientHello, thus preventing tampering
> with that.

#1 & #3 are easily dealt with by injecting bogus 0-RTT messages that get rejected, at which point a 0RTT could be prevented and we won't get to #2.

So, the client sends a handshake with 0RTT, an intermediary strips it and replaces it with something that fills the slot, but will get rejected, the server rejects it and falls back to 1RTT, and then the client would have to accept this. This intermediary thus has the power to force any 0RTT attempt to fall back to 1RTT.


Dave