IETF Logo Mail Archive

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

Christian Huitema <huitema@microsoft.com> Mon, 28 December 2015 04:55 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 D16DE1A88A9 for <tls@ietfa.amsl.com>; Sun, 27 Dec 2015 20:55:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WRxGh1Oh3Y43 for <tls@ietfa.amsl.com>; Sun, 27 Dec 2015 20:55:20 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76751A88A5 for <tls@ietf.org>; Sun, 27 Dec 2015 20:55:19 -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=JFZ+xibaGErPHqQUprUzp3LYJaXLA1ehTvg8vWcBUE4=; b=LqxzHvIN0R4hSmJOJ2NyDGwofjKOWDVKjrh2rp5439nwCAgGCDZhKu0yCDlzBfwpo1/QZ0+KdAOoxRSaVO0spHou+MR06leL2l0syEsji1SdMzyhpuYCo93OcNlcwFem21gcucx2IlCThmyU3O66p0zLpAkrbSmA0fKBVFWzxdY=
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; Mon, 28 Dec 2015 04:55:17 +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; Mon, 28 Dec 2015 04:55:17 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Dave Garrett <davemgarrett@gmail.com>, 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/YA==
Date: Mon, 28 Dec 2015 04:55:16 +0000
Message-ID: <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>
In-Reply-To: <201512270208.11253.davemgarrett@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:5K/NXCYQ+1GO6gbmxupqSdElsWLaVAzjV9H+x0xTY6jwthfm4vv+VyigMDb+ibUALGl2oURgCuM3V2rWyFOTyQTkpsdpJhbwway/Lb3nRGjz5hoRvOxOIWeNW7ZWhck2pLYPltkEq8g4T7bQDTKZqQ==; 24:YMmFWCnFsgPEW7GUh/r4Hg39cr/eW+fRCkSS8kks/lENNfK0/zu/a2e5NmyMWAtlodfJqJkjEeMhF/7X1Y3/+tZxtHPLZJRYpuW0FGg7lQ8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656;
x-microsoft-antispam-prvs: <DM2PR0301MB06564C1710D53927F103E6ACA8FB0@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)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656;
x-forefront-prvs: 08041D247D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(199003)(189002)(5003600100002)(105586002)(10090500001)(54356999)(86362001)(5001960100002)(5001770100001)(93886004)(92566002)(5004730100002)(5008740100001)(97736004)(5002640100001)(586003)(189998001)(99286002)(81156007)(15975445007)(66066001)(11100500001)(102836003)(6116002)(3846002)(77096005)(1096002)(1220700001)(106356001)(76176999)(8990500004)(74316001)(2950100001)(5005710100001)(122556002)(10290500002)(33656002)(101416001)(87936001)(2900100001)(10400500002)(86612001)(19580395003)(76576001)(19580405001)(40100003)(50986999); 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: 28 Dec 2015 04:55:16.7159 (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/e_i9kaU0jWCxLsaO5sMBaVw-1TA>
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 04:55:24 -0000

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?

-- Christian Huitema

v2.23.0 | Report a Bug | By Email