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 01:09 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 840C51A8825 for <tls@ietfa.amsl.com>; Thu, 24 Dec 2015 17:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 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, J_CHICKENPOX_12=0.6] 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 mBPnQJFDba5s for <tls@ietfa.amsl.com>; Thu, 24 Dec 2015 17:09:05 -0800 (PST)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 8EBD01A87F2 for <tls@ietf.org>; Thu, 24 Dec 2015 17:09:05 -0800 (PST)
Received: by mail-yk0-x231.google.com with SMTP id k129so26523659yke.0 for <tls@ietf.org>; Thu, 24 Dec 2015 17:09:05 -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=V9yRy25EftyvaYwc/8T+2IBPf1MYtjMkf7gI+KcH2JY=; b=biOcHVkkROIj+5/ooNuetnKTx6stCQVIFKbmesu/K0biGwwjz+/WEyDOrr8cANqZue TUZKFr1pwZpSz4/BBYUIhHGZ2rkEgRUYyJzsQ+cwqSSqjSI8tI7271lG5m2Jfgdntipl 9q60xerETbl993GtOOO4A8RgI5x5fowPvCUQLDLhxGsDTmPjlDOJxhrAgRz0YPOl3FbC TDgebFRmLDC2ahn0rIfEg8yAT9YILPWSYqwzaPPHtw0EHDHzaCby2pYYC/adpAihK3TT akH7iZcx2pMDSREAoceHko1B/kv9qxfG8p2V9hl4WpEr1mp2gU8BQ43D+3L1tcUub2K5 DGpw==
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=V9yRy25EftyvaYwc/8T+2IBPf1MYtjMkf7gI+KcH2JY=; b=gKocg4DrKHpcMY5ZCTo6MmBoNqX9WdG3g+9eYZmL+1DpVaWJgZT/2dKWiW8InMCKIu KGs+nAFIe9I2uPKF255FGBcwbE0QodY/fSVR1G0dWioATZqygAYR+rsGBrriYd2gKlMy Zefbor3zDk8jvasl6f6PEUMwNM9m0uT/45pkivTU4+HUSUpe31xjDbxhoSeZrSaP8ide tuEsiCfo/zuJLuw8J8AU78yjPjSJ3UcnG3sZ5lfOYVEVk+qlUPbBTCZ23U6CIDS7mHfc qMywfgmTM5D0VcgIGIGLUB4REz9rmDQ80XP53RMErfwdDDmAyTufKvSq2MlvuqmV/3Ac VciA==
X-Gm-Message-State: ALoCoQlZNOq+ptG75ocekoETM7E7LIL04ox0CV02T34iVC2Zb2KFW3KRH0YM+1LXiNDb/BGxD9YahlYosK63av3DCFUFWxRf+A==
X-Received: by 10.13.193.4 with SMTP id c4mr34679013ywd.192.1451005744890; Thu, 24 Dec 2015 17:09:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Thu, 24 Dec 2015 17:08:25 -0800 (PST)
In-Reply-To: <201512241748.25385.davemgarrett@gmail.com>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 24 Dec 2015 20:08:25 -0500
Message-ID: <CABcZeBMDXrCxjp+RtHGsxsZRGjEUJOy8BCxRLu4pMbFXkNcnEA@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=001a114caa9efdf7550527ae99b6
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/c-rTlzl9TB1HEmOTgD-Vz8ALjfM>
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 01:09:07 -0000

On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <davemgarrett@gmail.com>
> > wrote:
> > > 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:
> > > 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.
> >
> > This doesn't sound correct.
> >
> > 1. The client sends a ClientHello with an EarlyDataIndication indicating
> > configuration=C (and server key g^s) and ClientHello.key_share = x.
> >
> > 2. The server processes the ClientHello and determines whether 0-RTT
> will  be accepted
> > or rejected based purely on the ClientHello. I.e., it doesn't need to
> read any more messages
> > before deciding this [0]. If it decides to accept 0-RTT then it expects
> the next messages to
> > be 0-RTT handshake messages encrypted with SS = g^xs. If those messages
> don't decrypt
> > properly, then it needs to fail the entire connection (fatal alert with
> bad_record_mac).
>
> 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.


> 3. The attacker *could* modify the ClientHello to replace C with C',
> which would cause
> > the server to fall back to 1-RTT, but then the server's
> CertificateVerify and Finished would
> > both be incorrect, causing the handshake to fail when the client tries
> to process them.
> >
> > If you still think I'm wrong here, it would help me if you provide a
> ladder diagram indicating
> > the attack you are concerned about.
> >
> > Thanks,
> > -Ekr
> >
> > [0] Technically speaking, it should be possible to send ServerHello
> before
> > even reading  the remainder of the first flight.
>
> Also, I found a typo in the early data section. The config ID was referred
> to by two names. PR filed. ;)


Merged.

-Ekr


>
> Dave
>