RE: aes128gcm: why verify padding?

"Manger, James" <James.H.Manger@team.telstra.com> Mon, 30 January 2017 02:34 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD65128AC9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Jan 2017 18:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.12
X-Spam-Level:
X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com
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 3OtKdUuALmdx for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Jan 2017 18:34:31 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E235C1298D2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 29 Jan 2017 18:34:30 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cY1kA-00087b-Sf for ietf-http-wg-dist@listhub.w3.org; Mon, 30 Jan 2017 02:30:58 +0000
Resent-Date: Mon, 30 Jan 2017 02:30:58 +0000
Resent-Message-Id: <E1cY1kA-00087b-Sf@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <James.H.Manger@team.telstra.com>) id 1cY1k3-000860-QO for ietf-http-wg@listhub.w3.org; Mon, 30 Jan 2017 02:30:51 +0000
Received: from ipxcno.tcif.telstra.com.au ([203.35.82.208]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <James.H.Manger@team.telstra.com>) id 1cY1jq-0004p5-77 for ietf-http-wg@w3.org; Mon, 30 Jan 2017 02:30:46 +0000
X-IronPort-AV: E=Sophos;i="5.33,309,1477918800"; d="scan'208";a="19901256"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 30 Jan 2017 13:30:05 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8423"; a="277679320"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcani.tcif.telstra.com.au with ESMTP; 30 Jan 2017 13:30:05 +1100
Received: from wsapp5862.srv.dir.telstra.com (10.75.3.94) by WSMSG3753.srv.dir.telstra.com (172.49.40.174) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 30 Jan 2017 13:30:05 +1100
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5862.srv.dir.telstra.com (10.75.3.94) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 30 Jan 2017 13:30:03 +1100
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.126) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 30 Jan 2017 13:30:04 +1100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n5BXQAhDlcIftYTKZQfwBR3nBRmBWap6bL23YyKPGd0=; b=bUXbJoMbV05kJRkSKqlqeCxI5pltqGB10LzR2/7Gtt2IHSd2PyTaBhIAymbR2y0+vNQZofVtx2CFl2wndIXGZoWZhq9oe1zjqTNs0TzwG0gfcysuDtHN8gg/RRZvCJ2P5SIDQOiTHyiZrKYM/hjbIwnbm0K/nxpYAY1cYooE8ew=
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 30 Jan 2017 02:30:04 +0000
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0860.024; Mon, 30 Jan 2017 02:30:04 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>
CC: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: aes128gcm: why verify padding?
Thread-Index: AdJvg9D1nChV1RXVTGiVAO+6sRrzlwADDv6AAAAcAeAADb7rAAFW7FVwAAoO2IAACMzpgAAYx0WAAAAn4DAAZJKWgAAzIAMQAA8vZIAAi3LTUA==
Importance: low
X-Priority: 5
Date: Mon, 30 Jan 2017 02:30:03 +0000
Message-ID: <SYXPR01MB16157AC6FFBC54BA8A046AF6E54B0@SYXPR01MB1615.ausprd01.prod.outlook.com>
References: <CABkgnnUo-tf69AzJC=OUy2rjDZwedTd5Ua9mhOiJBqaA0VKrYw@mail.gmail.com> <SYXPR01MB16150F4D3D19CC69D18E1A09E57D0@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnV_OatRWyZBE3Rak22gS1jrOZKjCGwOePpbqJCAeJFM4Q@mail.gmail.com> <SYXPR01MB1615DD56268D7EF9929F3DBFE5720@SYXPR01MB1615.ausprd01.prod.outlook.com> <20170123073623.GA28101@LK-Perkele-V2.elisa-laajakaista.fi> <SYXPR01MB1615798CC057FB3232B2FA4BE5720@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnW4e+FOz+gsu6vZ2d9WOSv9Yohn+OejrNom9HCBiMrRWQ@mail.gmail.com> <SYXPR01MB1615AE56D810A0372AF811FCE5750@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnWoSWCeV_TUwDY1J00ivY0TDgU_9NhiSWZpM4_F6XAYfA@mail.gmail.com> <SYXPR01MB1615C769ADDAF813BB32A65DE5760@SYXPR01MB1615.ausprd01.prod.outlook.com> <20170127072041.GA16072@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20170127072041.GA16072@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com;
x-originating-ip: [203.41.142.244]
x-ms-office365-filtering-correlation-id: 4eeadf71-d38e-4ced-85fe-08d448b7e5f0
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1615;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1615; 7:LrZ/RADLy8pOM0E52UsmeLGPGNfdn6tHP3iaj8LKQyCZaYAKWPLwtvdOZOBbQJtQMSiEwjKYiH1+tz/d+WSbtqPg+S9u74u9OtVz450b8AfU4VPH4IHqZvF7Zl16EbpFb8GqAm5fC9monQABwIBagM3VMOlyK+YY0C5Tm4+b6kFsP9Dcn+vevIIgif05IYCKyU0LcOogd+iwX8xNfS9jv4GpTlBgJuRqozkkxY+iGD93afECvrDfnBVXqIHwutnNb9i/ijW0uGvk9PdgHbHdeoc0UBrIeS2jrXA2uHRZeZ6ZWX3IApBpjP70ncymT3A3fNcnKdGI0W8RugmXaoQXxk/OaICQlLS2osNxYcIOdjNB2T6AG5ox4HVekXcDB+CDqcPhqaxsJGGtpjXjx+dklsiCsffoIPepwQYfjVOFr6Pxx+C0+l6QB7mFWcqrUOnnOKPy3zYk+3D66YoDDUb39Q==
x-microsoft-antispam-prvs: <SYXPR01MB16156DCF07EECB4586B4F11BE54B0@SYXPR01MB1615.ausprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:SYXPR01MB1615; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1615;
x-forefront-prvs: 0203C93D51
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(199003)(122556002)(7696004)(4326007)(3280700002)(66066001)(33656002)(77096006)(3660700001)(2900100001)(229853002)(55016002)(99286003)(2906002)(6506006)(54906002)(38730400001)(92566002)(39060400001)(2351001)(6436002)(5640700003)(105586002)(15650500001)(9686003)(93886004)(106356001)(86362001)(25786008)(101416001)(110136003)(5660300001)(6116002)(97736004)(189998001)(3846002)(102836003)(81686999)(74316002)(50986999)(305945005)(7736002)(54356999)(53936002)(8676002)(8936002)(1730700003)(81166006)(76176999)(81156014)(68736007)(2501003)(2950100002)(6916009)(42882006); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1615; H:SYXPR01MB1615.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 02:30:03.9082 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1615
X-OriginatorOrg: team.telstra.com
Received-SPF: none client-ip=203.35.82.208; envelope-from=James.H.Manger@team.telstra.com; helo=ipxcno.tcif.telstra.com.au
X-W3C-Hub-Spam-Status: No, score=-2.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, W3C_NW=0.5
X-W3C-Scan-Sig: mimas.w3.org 1cY1jq-0004p5-77 4b0a6d6dc96e29be937cb2a7c86ef0de
X-Original-To: ietf-http-wg@w3.org
Subject: RE: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/SYXPR01MB16157AC6FFBC54BA8A046AF6E54B0@SYXPR01MB1615.ausprd01.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33388
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

>> I was hoping for an anti-truncation mechanism that didn't depend in a
>> not-completely-obvious-to-me manner on a seemingly quite separate aspect:
>> the KDF. For instance, even with no KDF (for key or nonce) having a byte
>> distinguishing start/middle/end would be sufficient to authenticate you
>> have received an authentic prefix or suffix or complete message.

> Actually, if you don't use KDF to obtain the nonce base together with
> the key, attacker can corrupt messages unless you actually verify that
> the start block is in its proper place.

Is this because the scheme uses Nonce XOR Index (not Nonce + Index)?
Given 2 valid AEADs, you can get the XOR of their indices but that isn't enough to tell how far apart they are in a sequence. It isn't even sufficient to tell that one comes right before the other. Hence, you really need to get the AEAD marked "start" first (or get the salt from which the "start" record's nonce is derived).

> This is because if attacker can choose noncebase, attacker can reorder
> the blocks so all decrypt properly.
>
> Using KDF prevents this because attacker can't produce suitably
> related noncebase pairs for the same key

--
James Manger