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

Eric Rescorla <ekr@rtfm.com> Thu, 24 December 2015 21:44 UTC

Return-Path: <ekr@rtfm.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 7E35F1A6EDA for <tls@ietfa.amsl.com>; Thu, 24 Dec 2015 13:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 gFMCxeSJ1FqD for <tls@ietfa.amsl.com>; Thu, 24 Dec 2015 13:44:41 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 E47A81A6ED9 for <tls@ietf.org>; Thu, 24 Dec 2015 13:44:40 -0800 (PST)
Received: by mail-yk0-x235.google.com with SMTP id p130so230421140yka.1 for <tls@ietf.org>; Thu, 24 Dec 2015 13:44:40 -0800 (PST)
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:content-type; bh=tsPcY96AoU9fb285sa+KZVhZFgke9UyxZZnnB12ooVM=; b=03L7IeUuwSf8X6sRwYLBoha2aW/gfAvwrggXdWLplqqvHeh0Eu8PkG32pb9bPxtDnX 7ixW6iVoApOjOWq/G327/yTi+WYYVmq8497b+7Gf3Q9AehPvlOtTWK266bb49HAHBF5l ljfOztNUL2B+VdzKDFz8pWGLm3drdfQTlNgqLCGhMN9VnhlOQdCutSNpKxBQMmX4AzwN IcQefFXN4poJ/UmoTRyd57uYyDPp9mYAHR2iK3pDto1YJUrJxqBmqrx90bEZqnUjdP0D oOwCQ0xIF1Kuu6G3CWAmrwHRUFznF/xj5I9kl1MAjKMX29wKsy/MTZ7c6XtBeRismxzl MvfA==
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:content-type; bh=tsPcY96AoU9fb285sa+KZVhZFgke9UyxZZnnB12ooVM=; b=Mz35l0io4LCde9djwL7Mf4w/Rcf6LAYlufFczwYRN5xYHvdrqnMhZ5bJ0rUETaawXs 93DwrlDITKouq8dYw9VDiF61N+Vj7Rw5X3SWm07ttDZgSj0XMDy86FmmXNxi031WDMCK 5swP92YlEYAXggJawxX6Pf1ocD6WDXKKRoey9hLZL+zhoUC3Jjp8ow1DgKEquIr5R6vZ myqnkpQ7FjNl8HAt9pL4KoEivrc/uCVtY/+Zd6i0AKQO0NusoAzXzPGoEq5mYfG30Fw9 riFc/PBJTRxHzWguh3LBOOLBQxKfH8a2Ob6kNuuCx6ZanSSillB0EAXxfbai8bQzspma G9bQ==
X-Gm-Message-State: ALoCoQkqlPZZsDPCLF3Yya9uyPZp5OTd4y9ROwzvNmdbmURFM74z6KuXEX86YpeFtpSjU/xx4q6fSzEW/5PsLq5eWWBoVT+Heg==
X-Received: by 10.129.73.133 with SMTP id w127mr33059400ywa.223.1450993480215; Thu, 24 Dec 2015 13:44:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Thu, 24 Dec 2015 13:44:00 -0800 (PST)
In-Reply-To: <DM2PR0301MB065563D16424BA687357EAB3A8E70@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <CABcZeBO3F067nJ=maZDbH4-jg1kFZwck7qXUOYbttr3VO9Ykrg@mail.gmail.com> <DM2PR0301MB065553EAD2849CF405A3D33FA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <CABkgnnVZNbXWX-4xx-tS2nPv34btbPmkQVk2m5pVAP2XJsZ2KA@mail.gmail.com> <DM2PR0301MB065563D16424BA687357EAB3A8E70@DM2PR0301MB0655.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 24 Dec 2015 16:44:00 -0500
Message-ID: <CABcZeBMrS2wHHiW0eEZXFNnJpLtsDFZS0VSKZCXjDk5oXNGffQ@mail.gmail.com>
To: Christian Huitema <huitema@microsoft.com>
Content-Type: multipart/alternative; boundary=001a114dcf6af603870527abbed9
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qVLYxy5DDZSV3-VK8d_XZnTBsMo>
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 21:44:42 -0000

On Thu, Dec 24, 2015 at 3:40 PM, Christian Huitema <huitema@microsoft.com>
wrote:

> On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote:
> >
> > On 22 December 2015 at 13:25, Christian Huitema <huitema@microsoft.com>
> > wrote:
> > >> Unless I'm confused (which is possible given the time of night),
> > >> the intention, as you say, is to separate out the 0-RTT handshake
> > >> messages i.e., (cert, cert verify, finished) from the 1-RTT
> computations.
> > >
> > > OK. That does not simplify implementations using running hashes...
> >
> > It does if you consider the possibility of having to drop the 0-RTT data.
>
> That's right. In fact, it may be a good idea to add to the spec a
> description of a "Failed 0-RTT handshake." If I understand correctly, the
> following will happen:
>
> * Server will receive the client hello, ignore the Early Data Indication
> extension, and proceed as in 1-RTT.
> * Server will indicate that by not adding an Early Data Indication to the
> server hello.
> * Server will receive a series of 0-RTT messages that it cannot decipher,
> and just drop the messages.
> * Client will receive server hello, and proceed as per 1-RTT. Client API
> will signal that 0-RTT data was lost, application may decide to retransmit.
> * Server may send client authentication requests. Client will have to
> repeat the authentication messages, even if it already sent them as 0-RTT.
>

This seems exactly correct.


In that scenario, the handshake hash cannot include the 0-RTT messages,
> since the server does not in fact receive them, and they do not contribute
> to the state of the connection.
>

Correct.


We can of course debate whether the 0-RTT messages should also not be
> included in the hash if the 0-RTT exchange was successful, the messages
> were received, and they contributed to the state of the connection. If they
> are not included, then the "Finished" HMAC does not offer a protection
> against tampering. This may open the possibility of some kind of
> substitution or replay attack.
>

They are included in the client's 0-RTT Finished, so as long as SS is not
compromised, you should not be able to modify them. They are not protected
against modifications if SS is compromised, whereas other messages are
covered by the server's signature.


The failed 0-RTT handshake scenario also has interesting consequences on
> the Record layer. We have a legitimate scenario in which received records
> cannot be decrypted. This should not trigger alarms. And the numbering
> scheme should be robust against these missing records.


Yes. Resetting the sequence number as proposed by Fournet et al. and
in WIP-11 makes this easier.

-Ekr