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

Eric Rescorla <ekr@rtfm.com> Fri, 25 December 2015 14:11 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 152481A014C for <tls@ietfa.amsl.com>; Fri, 25 Dec 2015 06:11:16 -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 0sKM56dEDL1L for <tls@ietfa.amsl.com>; Fri, 25 Dec 2015 06:11:14 -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 F2A081A0115 for <tls@ietf.org>; Fri, 25 Dec 2015 06:11:13 -0800 (PST)
Received: by mail-yk0-x229.google.com with SMTP id x67so56348216ykd.2 for <tls@ietf.org>; Fri, 25 Dec 2015 06:11:13 -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=c2hNEOFSEqALCrErbhw64a2wzkGf+/OAn88WSHm8sdY=; b=pwVdPZUBw3MPWIyd/E5SUfauE+JfxXUx9u7KJFYm1uEK/l6hRYsIRLPDffBpKJthqx 5+pkgvfunBqAnHBf8++QSX4ghIyOYb1PQeaBEnJOHXqWEei8ghLJUYYDJza3qFAlGf/L jmAgXstfVFtfVdyz6sq5gjQDaV1mWZajeI1R0bl0IDKtyThQjFuyHuk18Ygg+oIMLoQo 59HX2jTd+7SHJI1OeuUaCGeo9s5Jos2xGyk9jv0InJKnvg3EbbLuHhQjp0sv31hR+BrD XOdr56QmSKI4VtaMQlWPLDQdS/vfAcicEHqJdiws+Othu15wmBSyJQIRwY5jfB82bfmV L1Xw==
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=c2hNEOFSEqALCrErbhw64a2wzkGf+/OAn88WSHm8sdY=; b=P5ygPJDuTinKDPmloUgbXc05ITBdza/pW4xWrH/cYN5RKDejydgLa3oTy3TCg+e8VJ GQZpVkHQyFCJtQ6PnHvsPdK2o/JdCHLi25HtExTpGe+7xVyrnhup3TJ1rdxBgljH+Jo4 P4zMhaU4jE/pNoNbtISk+3aN58igrWyifRsIW4qorPXadA74AaHVwz2xYXEvYMFv/wv4 QmdoaJ9l8LNkthRWoHVAxOF7kBvUuAPIkpEygjX+Lzz4j5Ge5Y0FJNP889KrUXEcH3eA nyjhX52CpXCHsJmBxSyd99zgCiL2QYvlgy0GbReGC+9+3deCvnh5//c+6pSxyN89vMpU xkQg==
X-Gm-Message-State: ALoCoQk01rg54l3K3QkZLUQ4FraDRMUyvfz5zZxPxjHEVfqVNZ/wAXzu3x527yWmfutQbZdH7ge4Gc9GxbwzbACn9zYAH41OCA==
X-Received: by 10.129.148.3 with SMTP id l3mr31258213ywg.155.1451052673230; Fri, 25 Dec 2015 06:11:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Fri, 25 Dec 2015 06:10:33 -0800 (PST)
In-Reply-To: <20151225080417.GA2800@LK-Perkele-V2.elisa-laajakaista.fi>
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <201512241701.49373.davemgarrett@gmail.com> <CABcZeBM8i=iMF_9VYfkCOYZ5kso=70S-t4sX-jh+2AgFPf8iGw@mail.gmail.com> <201512241748.25385.davemgarrett@gmail.com> <CABcZeBMDXrCxjp+RtHGsxsZRGjEUJOy8BCxRLu4pMbFXkNcnEA@mail.gmail.com> <20151225080417.GA2800@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 25 Dec 2015 09:10:33 -0500
Message-ID: <CABcZeBOqQ0Jju6okpvF_26BV1_f+nA-THDVgdN=1vHEBTJf-vA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=94eb2c07c8bc239ae70527b98725
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/twkopbFSR6H2j9Mf2XMJ6S9UIqU>
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: Fri, 25 Dec 2015 14:11:16 -0000

On Fri, Dec 25, 2015 at 3:04 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail.com>
> > wrote:
> > >
> > > This last bit stops this, yes. I would prefer the spec say this very
> > > explicitly, as right now it doesn't and all I see is a line saying:
> > > "If any of these checks fail, the server MUST NOT respond with the
> > > extension and must discard all the remaining first flight data (thus
> > > falling back to 1-RTT)."
> >
> > Well, this is a general requirement any time the record MAC is bad:
> > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2
> > "If the decryption fails, a fatal “bad_record_mac” alert MUST be
> generated."
> >
> > > 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.
>
> Except that when server is doing 1RTT fallback and skipping 0-RTT data,
> then records that get deprotect failure (is that the proper term?) are
> ignored instead of generating bad_record_mac like "normal" deprotect
> failure would.
>
> Then there's also the case where server is skipping 0-RTT data for retry
> (there one can recognize end of data from content-type 23 changing back
> to 22).
>

Correct. These need to be special cased. And of course with DTLS you
just drop such packets rather than terminating the connectin.

However, it's worth nothing that even if the first-flight handshake data
weren't encrypted, it would still not be possible to create confusion
here because the server would still be waiting for the 0-RTT Finished
message prior to being willing to accept application data from the
client.




Then one has to ensure that configuration_id's are never reused: If
> client and server disagree about server-valid configuration, the result
> can easily be hard failure (instead of fallback).
>

Yes, agreed. I had always assumed that configuration ids were unique.


One server-side trick to ensure non-reuse would be to hash the server
> certificate and the configuration messages (with configuration_id being
> zeroes of approriate length) using e.g. SHA-256 and then use the resulting
> hash as configuration_id.
>


-Ekr


>
>
>
>
> -Ilari
>