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

Eric Rescorla <ekr@rtfm.com> Mon, 28 December 2015 11:46 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 E159F1A9062 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 03:46:45 -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 5ue3sA0JkUn3 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 03:46:43 -0800 (PST)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 F36B11A905E for <tls@ietf.org>; Mon, 28 Dec 2015 03:46:42 -0800 (PST)
Received: by mail-yk0-x229.google.com with SMTP id x67so99704126ykd.2 for <tls@ietf.org>; Mon, 28 Dec 2015 03:46:42 -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=D6MNgRw/Vd/wTuDLBhEg/XKzRYu2igE4eKfDlNRVZYA=; b=naaaC7NEwZA3upwX3rVtmkHM7hDBza5t/rwDyjOrSz5Aivy3mMInGPr7Gqs+qJEiWh HXA7XZVE6qGTcsPeWq7Hv1y2vbx2uwDoI13Fm73dNsjDsrsb7LCxZTqearQLTPxhfRSR /TYxULmsrStX+6F4pULKbyqIC1/N3Ln6rfUiEgpHcVIsSzksTwAzCpOx5+xrJsajDTsS rC+poOj+uVhelYCUt+Ko1sJE9LGhbh07ddBAFprwkiacLTVs2YVNnJcHmvFBVQf2lv2J M4GIBiCnfZCqVUk974MFjS63S+keSWWmGTLAeOAeSLX+t/JI7w+cp4UMwKqpmOHKwdIh v0Nw==
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=D6MNgRw/Vd/wTuDLBhEg/XKzRYu2igE4eKfDlNRVZYA=; b=BX0A0L0ljc8rLTPg3GHh8OFJfYBBszfN0j8K1tilN2iJJCmPA86s93DNEr49vrPHJ7 1YFc3l+vyEaIGtVA/yI5cIMlqOv0wlOctdHeuM9UUWwYhB1MXQdAxrO/TN6JgU7zG5eo OloHzqKM7VeqxuManuUbNTH+JwKFiKchifjbXVvQzYcaUoqozAHaKKmLXrjxQ5FnH8x8 oK1tkTi6Ifcu8uhNusA7ZnZysbErVjTRXyRC/oEXS4axwHxv7TzNdKXT+VJIi4u0Uhnp kQewkYnVcTbb9kah0SfPbgCWlHWgnlPX/rz5pG6alfOuiw3mzufPGRgeqqitJfa5v4yz jYbA==
X-Gm-Message-State: ALoCoQlgbzW1iNIoUZ6Gz3hR7007igzMLi2p9jW1DUXKVTgjsYoHAFCWmapeFWjqmcrbH7cIj3Q99nTmStpqZ1xONBgyHYepXg==
X-Received: by 10.129.153.3 with SMTP id q3mr45349737ywg.231.1451303202198; Mon, 28 Dec 2015 03:46:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 03:46:02 -0800 (PST)
In-Reply-To: <DM2PR0301MB06557834035ECF047BC3F88AA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <201512241748.25385.davemgarrett@gmail.com> <CABcZeBMDXrCxjp+RtHGsxsZRGjEUJOy8BCxRLu4pMbFXkNcnEA@mail.gmail.com> <201512270208.11253.davemgarrett@gmail.com> <DM2PR0301MB06557834035ECF047BC3F88AA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 28 Dec 2015 06:46:02 -0500
Message-ID: <CABcZeBNNGn1uGRShCnNtowrieaXM6rUTky+=wq=bRGtjm660Jg@mail.gmail.com>
To: Christian Huitema <huitema@microsoft.com>
Content-Type: multipart/alternative; boundary=94eb2c0bbfaed46ae60527f3dbc1
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HXx3Ocz9jvWIq9GbJlui47uYvjg>
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: Mon, 28 Dec 2015 11:46:46 -0000

On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <huitema@microsoft.com>
wrote:

> On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote:
> > On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote:
> > > Well, this is a general requirement any time the record MAC is bad:
> > > See
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftlswg.gith
> > ub.io%2ftls13-
> > spec%2f%23rfc.section.5.2.2&data=01%7c01%7chuitema%40microsoft.com%7
> > c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4
> > 7%7c1&sdata=nTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d
> > > "If the decryption fails, a fatal “bad_record_mac” alert MUST be
> generated."
> > >
> > > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail.com>
> > > wrote:
> > > > The current text doesn't explicitly say how to handle 0-RTT data
> that it
> > > > thinks it should be able to decrypt but can't. After rereading
> things a bit
> > > > I think you're correct in that the correct course of action the spec
> > > > currently expects is to abort, however implementers frequently err
> on the
> > > > side of working partially vs not at all when given any wiggle room.
> A clear
> > > > hard "MUST abort" on failed decrypt of 0RTT data would deal with
> this and
> > > > avoid any other possible misunderstanding. Either do or do not; no
> try.
> > >
> > > If you have suggested text, I'd be happy to see a PR.
> >
> > Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT records
> aren't
> > allowed special treatment and errors on handling MUST NOT result in a
> 1-RTT
> > fall back.
>
> Isn't that a part where TLS and DTLS will differ a lot?
>
> For DTLS, we have to consider the packet injection threat. It is fairly
> easy to send some random bytes with a fake source to a UDP destination.
> Such attacks should not cause the DTLS association to fail! The normal
> behavior ought to be to just ignore UDP packets that fail to decrypt. This
> would cause 0-RTT rejects to just result in dropped packets. Can we ensure
> that the handshake protocol is robust against that?
>

We obviously need to distinguish here between handshake and application
data messages, because DTLS is intended to allow loss of application data
messages.

WRT handshake messages, as I indicated before, I believe that there is
enough information in the handshake messages to prevent removal.
Namely:

1. The ClientHello contains an indication that 0-RTT handshake messages
are coming.
2. The Client's 0-RTT Finished contains a MAC of all the Client's
0-RTT messages.
3. The Server's Finished contains a MAC of the ClientHello.

Thus, provided that the client and server in fact share a configuration
(which, again, is in the ClientHello) then the server knows at the time
of receiving the first-flight Finished that he has (or has not) received
all the client's 0-RTT Handshake messages. [0].


The more interesting question, however, is what drives the DTLS state
machine forward to ensure progress in the face of innocuous loss.
The basic DTLS design is that the receipt of the first message of the
peer's next flight indicates receipt of the entire flight. In this case,
then, the receipt of the ServerHello would indicate receipt of the
Client's 0-RTT Finished. However, this would place a requirement
that the server not *send* the ServerHello until that point, which we've
left open in WIP-11 by not hashing in the 0-RTT plaintext.

-Ekr

[0] Note, however, that the client has to rely on the server to handle this
properly. The reason