IETF Logo Mail Archive

RE: aes128gcm: why verify padding?

"Manger, James" <James.H.Manger@team.telstra.com> Mon, 23 January 2017 12:52 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 6215D1295F1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 23 Jan 2017 04:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 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, 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 IrCTSuIh9sSo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 23 Jan 2017 04:51:59 -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 D38CA1295F6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 23 Jan 2017 04:51:59 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cVe2t-0004lb-1k for ietf-http-wg-dist@listhub.w3.org; Mon, 23 Jan 2017 12:48:27 +0000
Resent-Date: Mon, 23 Jan 2017 12:48:27 +0000
Resent-Message-Id: <E1cVe2t-0004lb-1k@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) 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 1cVe2n-0004k2-9x for ietf-http-wg@listhub.w3.org; Mon, 23 Jan 2017 12:48:21 +0000
Received: from ipxcvo.tcif.telstra.com.au ([203.35.135.208]) by titan.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 1cVe2f-0003jp-76 for ietf-http-wg@w3.org; Mon, 23 Jan 2017 12:48:15 +0000
X-IronPort-AV: E=Sophos;i="5.33,274,1477918800"; d="scan'208";a="20431846"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 23 Jan 2017 23:47:39 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8416"; a="383415015"
Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcavi.tcif.telstra.com.au with ESMTP; 23 Jan 2017 23:47:39 +1100
Received: from wsapp5871.srv.dir.telstra.com (10.75.139.13) by wsmsg3702.srv.dir.telstra.com (172.49.40.170) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 23 Jan 2017 23:47:39 +1100
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5871.srv.dir.telstra.com (10.75.139.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 23 Jan 2017 23:47:38 +1100
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.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, 23 Jan 2017 23:47:38 +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=dOFe1r7Yp+R5AOvR2WkK5Ml5GW7jtNN/f9Lok/njWzI=; b=B/SLy4NzG0/5/P9aunl1N28y4uOd+nFT07HVL7lTuT2c6taNx3WsdDPfDxhArPGbu/McQFoIxP73TUw8O/wMbVmuog/23dr8PJ4EeNzdPFkKdWN9l36rLpEQZ/eURsgZHFbxlnyMTIhVc07zw/J4Gy6BJ3v1tqKcGZ7zc/zV2/c=
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1616.ausprd01.prod.outlook.com (10.175.209.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 12:47:37 +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.021; Mon, 23 Jan 2017 12:47:37 +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+6sRrzlwADDv6AAAAcAeAADb7rAAFW7FVwAAoO2IAACMzpgA==
Date: Mon, 23 Jan 2017 12:47:37 +0000
Message-ID: <SYXPR01MB1615798CC057FB3232B2FA4BE5720@SYXPR01MB1615.ausprd01.prod.outlook.com>
References: <SYXPR01MB161520224A59CDCE0D433A2CE57A0@SYXPR01MB1615.ausprd01.prod.outlook.com> <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>
In-Reply-To: <20170123073623.GA28101@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: [124.188.240.233]
x-ms-office365-filtering-correlation-id: 4eab2371-22e6-4c3e-5f35-08d4438e028f
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1616;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1616; 7:GVWcM4WdtYn+L3aeq/FQ1cQwx2/Ph5c3yQWVp4rqo9+KOI1syv0YWUrD9Nupq/fzEecjczqCrLs3LucIT3fLAPchOgwlU0i1Zp7XbFzkSwRaFVz4D08VGuKv+6z2YzdX0wQzLQYBs2rsOGLDf5ZYAKw95GUUA7F/UIZUDbx30T/XlM0OckIKb/LRtbIiRFDZjAayysKCYf+Pc5MYGZddMOU5ftzOsKPRRDqyMmY0t4UZnpZKW1YCFyEHQtQ11R3Wz8JMNuZdn4sSvExtoSo89nJcekxtxN9Aq7a2QzWVwAQvMeNgfnL2lPx+XtlY1+wrUni4TD3d24q94aKZQZr5v15QwTNzJIbNjNqq+zMji1LdPySvr3BENxnloDGhkxyyPQqH5ohOm/+ibeDqFDqbOuHMigqF3vd2xxwRvwbJZFsXSJu8EOcRGw0PECYsZZn2E4qvcndwbz3I38ikABjcnQ==
x-microsoft-antispam-prvs: <SYXPR01MB1616646AA30CAB07ECBE08D8E5720@SYXPR01MB1616.ausprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(272811157607776)(67441168502697);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(6042181); SRVR:SYXPR01MB1616; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1616;
x-forefront-prvs: 0196A226D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(13464003)(24454002)(377454003)(74316002)(305945005)(86362001)(105586002)(7736002)(189998001)(54906002)(25786008)(229853002)(77096006)(39060400001)(97736004)(38730400001)(55016002)(6506006)(6436002)(5640700003)(110136003)(99286003)(6306002)(9686003)(66066001)(2501003)(3280700002)(3846002)(6116002)(2950100002)(2351001)(4326007)(102836003)(42882006)(6916009)(106356001)(7696004)(92566002)(1730700003)(8676002)(33656002)(5660300001)(81156014)(15650500001)(2906002)(81166006)(101416001)(2900100001)(53936002)(68736007)(76176999)(3660700001)(93886004)(122556002)(54356999)(8936002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1616; 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: 23 Jan 2017 12:47:37.1868 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1616
X-OriginatorOrg: team.telstra.com
Received-SPF: none client-ip=203.35.135.208; envelope-from=James.H.Manger@team.telstra.com; helo=ipxcvo.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, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1cVe2f-0003jp-76 a3735bcfb3c3bb48029837cfb44796c1
X-Original-To: ietf-http-wg@w3.org
Subject: RE: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/SYXPR01MB1615798CC057FB3232B2FA4BE5720@SYXPR01MB1615.ausprd01.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33357
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>

A padding byte to distinguish intermediate and final records could indeed work.

It doesn't consume any extra bytes in this scheme as it piggy-backs on an end-of-padding byte. But in a different multiple-AEAD-record scheme that didn't offer padding (a nice, but not strictly necessary feature) it wouldn't be so ideal. I've seen ideas to put the first-vs-intermediate-vs-last indicator in the nonce, in the KDF, in the AAD, in the record length, and now in the plaintext. I'm not sure how to pick.

What do you do if last non-zero byte isn't 0x01 or 0x02?

> And while we are at breaking things, it would be good time to make
rs count ciphertext, not plaintext, right?

That's already in the editor's draft (https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-encryption-encoding.md)

--
James Manger

-----Original Message-----
From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] 
Sent: Monday, 23 January 2017 6:36 PM
To: Manger, James <James.H.Manger@team.telstra.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; ietf-http-wg@w3.org
Subject: Re: aes128gcm: why verify padding?

On Mon, Jan 23, 2017 at 04:28:55AM +0000, Manger, James wrote:
> After implementing aes128gcm I have another reason to adjust the
> padding scheme. Putting the content first, before the padding
> (whatever format), will save moving the content after decryption
> in some (typical?) implementations. A Decrypt API will typically
> expect the content to be at the start of a given buffer. For
> instance, my implementation decrypts to a given buffer, but due
> to the current padding scheme (<padlen><padding><content>) then
> needs to copy the data to the start of the buffer (shifting it 2
> bytes backwards in typical no-padding situations). If, instead,
> the content came first then the data wouldn't need to be moved.
> 
> 
> So I would support a padding scheme similar to TLS 1.3:
> <content><non-zero byte><zeros…>.

Furthermore, if the nonzero byte was 0x01 for non-final blocks and
0x81 for final block (or any two different nonzero values), then
that would also solve the truncation flaw from last message, no?

And while we are at breaking things, it would be good time to make
rs count ciphertext, not plaintext, right?



-Ilari

v2.28.0 | Report a Bug | By Email | System Status