RE: aes128gcm: why verify padding?

"Manger, James" <James.H.Manger@team.telstra.com> Mon, 16 January 2017 01:10 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 35FBF127058 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 15 Jan 2017 17:10:25 -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 rfrliSyn_80Z for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 15 Jan 2017 17:10:22 -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 244FF1293E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 15 Jan 2017 17:10:21 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cSvlR-0001bG-9r for ietf-http-wg-dist@listhub.w3.org; Mon, 16 Jan 2017 01:07:13 +0000
Resent-Date: Mon, 16 Jan 2017 01:07:13 +0000
Resent-Message-Id: <E1cSvlR-0001bG-9r@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 1cSvlM-0001aT-Ny for ietf-http-wg@listhub.w3.org; Mon, 16 Jan 2017 01:07:08 +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 1cSvlF-0005am-KR for ietf-http-wg@w3.org; Mon, 16 Jan 2017 01:07:03 +0000
X-IronPort-AV: E=Sophos;i="5.33,236,1477918800"; d="scan'208";a="16958277"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 16 Jan 2017 12:06:26 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8409"; a="283029745"
Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 16 Jan 2017 12:06:27 +1100
Received: from wsapp5863.srv.dir.telstra.com (10.75.131.32) by wsmsg3757.srv.dir.telstra.com (172.49.40.85) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 16 Jan 2017 12:06:27 +1100
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5863.srv.dir.telstra.com (10.75.131.32) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 16 Jan 2017 12:06:26 +1100
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 16 Jan 2017 12:06:26 +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=IW4W1nTp4Fgtuwx2WRszRSNbhxz3iwsH2LchqlwmTYY=; b=oMwWuKkw973ETkXGkWrORTtsB1GGVdYM0KawLHL+qzpTfyZv5U9/Tv+/zvAYQU3Mwn6i9H0yjbChJR3uaORAkHC7kAWghWfdpfSLRLzLGCKoyaPNBqKEFJZumAwm28Z1aCgE37RhEB0RJDJrVKekWs+ZoGlelYRRhDARiZVfJaY=
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1613.ausprd01.prod.outlook.com (10.175.209.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Mon, 16 Jan 2017 01:06:23 +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.0845.013; Mon, 16 Jan 2017 01:06:23 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: aes128gcm: why verify padding?
Thread-Index: AdJvg9D1nChV1RXVTGiVAO+6sRrzlwADDv6AAAAcAeA=
Date: Mon, 16 Jan 2017 01:06:23 +0000
Message-ID: <SYXPR01MB16150F4D3D19CC69D18E1A09E57D0@SYXPR01MB1615.ausprd01.prod.outlook.com>
References: <SYXPR01MB161520224A59CDCE0D433A2CE57A0@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnUo-tf69AzJC=OUy2rjDZwedTd5Ua9mhOiJBqaA0VKrYw@mail.gmail.com>
In-Reply-To: <CABkgnnUo-tf69AzJC=OUy2rjDZwedTd5Ua9mhOiJBqaA0VKrYw@mail.gmail.com>
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.35.9.18]
x-ms-office365-filtering-correlation-id: 2e183f1e-a4e6-4c64-3d99-08d43dabe37f
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1613;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1613; 7:CueDKszV9b1r0VVG5KYxk0jTHEf18HRQgQjhdKAQzMFGORm5InkteKxfXlKYfIVr9xuQo/0f5LS/y5cRB1rcfJLzlkGKP0Wqn/hczkx9DMjO9scilD30mYN8tLJ0C3V54NJwL3Nj11e0p4zSVJ0p0GmQKhgA+xQ9pKJIzdHokm7caorAEgUr3peG+CjpTe1c36ALb7tlwWpfDUyJ+kMak7NZCZh6ETRnzuHY1NrgjtzCBOvtPc4Ilo3uY7YzSjD8Inw0jNpyOfb0H1Y8cbaWh6TrLzSLDdffxrEFMuoveUA2jVY7aLkmkhk8YxW94Ju8znC6na8lVPiwatlC2DXg+pJWo1T0BelgaMRSrwKVqzHWlUAYdHJqyriVoIVvM0qt/GaknyZUJuQxBK4J5XjyXwppkMb1exp5EYaHkJnpYh8PsaWRdMY/Kttd2O7LdXVTnGTMwtomWWrdQ9WyKOPzYA==
x-microsoft-antispam-prvs: <SYXPR01MB1613DEBAB8600A085C4F36BCE57D0@SYXPR01MB1613.ausprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(272811157607776)(67441168502697);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:SYXPR01MB1613; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1613;
x-forefront-prvs: 01894AD3B8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(24454002)(13464003)(189002)(199003)(122556002)(54356999)(229853002)(7696004)(101416001)(33656002)(110136003)(8676002)(81166006)(81156014)(50986999)(8936002)(106356001)(76176999)(5660300001)(105586002)(15650500001)(189998001)(2950100002)(2906002)(305945005)(97736004)(9686003)(77096006)(7736002)(6916009)(4326007)(66066001)(74316002)(3846002)(39060400001)(38730400001)(102836003)(6116002)(99286003)(55016002)(6506006)(86362001)(42882006)(6436002)(25786008)(3660700001)(68736007)(2900100001)(92566002)(3280700002)(27001); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1613; 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: 16 Jan 2017 01:06:23.0780 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1613
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: AWL=0.000, 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: mimas.w3.org 1cSvlF-0005am-KR 5bd6c960a00f486f7c1538c47587e1c9
X-Original-To: ietf-http-wg@w3.org
Subject: RE: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/SYXPR01MB16150F4D3D19CC69D18E1A09E57D0@SYXPR01MB1615.ausprd01.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33285
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 don't think that this warrants a change at this stage.

Drafts have been around for at least a year, though there have been incompatible changes as recently as last week. This isn't a trivial change, but it isn’t a hard one for implementers either.

> I don't think that's justification for a change, at least not in the format.  The API, certainly.

Theoretically, changing APIs is better. But many APIs have been set for a long time. Actually this scheme encourages the retention of streaming APIs — as long as they operate in record-sized chunks, instead of block-sized chunks. I think it would be good is the padding forced APIs to use record-sized chunks, instead of insecure block-sized ones.

My gut feeling is that a software engineer would only have to be a bit sloppy to implement the current padding scheme insecurely (on many underlying AEAD APIs), but would have to be malicious to be insecure with small changes to the padding structure.

> A secondary, though weak, reason for validating is to squash heartbleed-like uninitialized memory reads.

Improvement 2 is actually much better for this. The "internal" length (padding length) is calculated mod (external length - 2) so it can never be too large. 

--
James Manger

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, 16 January 2017 11:33 AM
To: Manger, James <James.H.Manger@team.telstra.com>
Cc: ietf-http-wg@w3.org
Subject: Re: aes128gcm: why verify padding?

I don't think that this warrants a change at this stage.

The reason for enforcing the checking was so that we could ensure that when people sent padding there was only one way to send it.  You are asking to allow variation, which I think needs stronger justification than you've provided.

A secondary, though weak, reason for validating is to squash heartbleed-like uninitialized memory reads.

Regarding AEAD APIs, yes, I'm aware that some libraries have bad APIs for AEADs (thanks openssl).  I don't think that's justification for a change, at least not in the format.  The API, certainly.


On 16 January 2017 at 12:51, Manger, James <James.H.Manger@team.telstra.com> wrote:
> draft-ietf-httpbis-encryption-encoding allows any amount of padding to 
> be added alongside the content being encrypted. The spec says the 
> receiver
> (decryptor) MUST confirm that every padding byte is 0x00. Why?
>
>
>
> I’m not sure how it helps to check the padding. It doesn’t make the 
> encryption deterministic as there is a salt involved, and the length 
> of padding can also vary. It isn’t useful for integrity as that is 
> provided by the GCM tag.
>
>
>
> Checking the padding could be harmful. Padding (to a block size) has 
> caused lots of security vulnerabilities when the padding is checked 
> before doing a proper integrity check. AEAD algorithms (such as GCM) 
> theoretically solve this, but only when receivers process a whole AEAD 
> decryption in one go, not via a (very common) streaming API.
>
>
>
> The aes128gcm Content-Encoding adds “app-layer” padding, but by 
> putting it first with a fixed format it is almost tempting receivers 
> to check it before processing the rest of the ciphertext, and hence introduce vulnerabilities.
>
>
>
> 3 possible improvements:
>
>
>
> 1.       Allow padding bytes to have any value. The receiver just skips
> them.
>
>
>
> 2.       Calculate the padding length by reducing a 2-byte unsigned integer
> modulo the maximum possible padding length (plaintext length – 2). 
> That means every 2-byte value will give a valid padding length.
>
>
>
> 3.       Put the 2-byte padding length field at the end. So the receiver has
> to have a whole AEAD plaintext block before knowing where the content 
> starts.
>
>
>
> A plaintext block would be: plaintext = padding || content || padlen
>
> Len(plaintext) is the record size - 16.
>
> Len(padlen) is 2 bytes.
>
> Len(padding) = padlen % (Len(plaintext) - 2)
>
> Padding bytes have any value.
>
> Content is the remainder of the plaintext block.
>
>
>
> The nice feature of this is that every plaintext block is valid. The 
> last 2 bytes can be anything; mod (Len(plaintext) - 2) always gives a 
> valid padding length; padding can be anything; and all that is left is 
> the content to pass to the next layer. With this arrangement there is 
> very little risk that plaintext structure is dangerously checked 
> before performing the AEAD integrity check.
>
>
>
> This form is no harder that the current structure to process, but it 
> does encourage proper use of AEAD APIs.
>
>
>
> --
>
> James Manger
>
>