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

Christian Huitema <huitema@microsoft.com> Tue, 29 December 2015 01:28 UTC

Return-Path: <huitema@microsoft.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 DCA111ACE77 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 17:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-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 sCFDUAaJT6YV for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 17:28:12 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F541ACE73 for <tls@ietf.org>; Mon, 28 Dec 2015 17:28:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vEWiR+ACzo0JrE9fLEx3m7O/yaaB6QWTax+B0Fda2Eo=; b=UGWQiGKX3fg3Ih7Z1uo2txkvHme2U7XlQbHM+BwcEn4J+GKq1T/0H7t8MZK+ZMTN5bNc+sx/YIHt+o9kkTa+3mNx12hjtiwjJByIx1rtHSW+rpLb5gXD1C7A+165eHY68kLzMUCPhxUw6KnLGj3EIPqIa+Ae5k6CVIfNYts7CmI=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 29 Dec 2015 01:27:49 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Tue, 29 Dec 2015 01:27:49 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQAAAGOBgACJ8x0AAAJUsIAAAMc6AAAAcr0AAABvnYAAATEtgAAE47KAAHElnwAALTC/YAAOzi4AAByvZ/A=
Date: Tue, 29 Dec 2015 01:27:48 +0000
Message-ID: <DM2PR0301MB06557E8D00424D7A600959D9A8FC0@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> <CABcZeBNNGn1uGRShCnNtowrieaXM6rUTky+=wq=bRGtjm660Jg@mail.gmail.com>
In-Reply-To: <CABcZeBNNGn1uGRShCnNtowrieaXM6rUTky+=wq=bRGtjm660Jg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
x-originating-ip: [72.235.151.78]
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:BzdkT/Tj4gXzd7bMZpTWztNBzLMGFQHSHpJzwsNI8EVPjkG7kgl5zSDG45c5oOFVrU6caX3sCcfKt5KquX4jFlmrsd6vMW5LoB7pc+VUHiPpjCZpIspJd6JC7FjBShQ7ObK07bOJ8f5v/zCpJS1djw==; 24:M3ubYiusqLguD1tnYoSYEAZ1ObWJPRbsLvgLS1/AaTrYwXhGf4zTz1Vnmr3oJNY4T1dQShkXk03FBMRI/al+aszkBy0Pi5Q7FaSnP/xb6/k=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656;
x-microsoft-antispam-prvs: <DM2PR0301MB0656E7A93EF9A784EF14F0B5A8FC0@DM2PR0301MB0656.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(189930954265078);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656;
x-forefront-prvs: 0805EC9467
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(199003)(189002)(2950100001)(5003600100002)(86362001)(11100500001)(54356999)(5001960100002)(105586002)(93886004)(66066001)(10090500001)(5004730100002)(92566002)(586003)(5008740100001)(99286002)(189998001)(5002640100001)(97736004)(81156007)(102836003)(15975445007)(77096005)(3846002)(6116002)(110136002)(1220700001)(1096002)(76176999)(106356001)(50986999)(122556002)(8990500004)(5005710100001)(2900100001)(10290500002)(74316001)(87936001)(33656002)(101416001)(10400500002)(86612001)(76576001)(40100003)(19580405001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2015 01:27:49.1142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SVl9RWNPgsIiyoMdKg9P6reEqcQ>
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: Tue, 29 Dec 2015 01:28:17 -0000


From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, December 28, 2015 1:46 AM
To: Christian Huitema <huitema@microsoft.com>
Cc: Dave Garrett <davemgarrett@gmail.com>om>; tls@ietf.org
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?



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