RE: aes128gcm: why verify padding?
"Manger, James" <James.H.Manger@team.telstra.com> Fri, 27 January 2017 01:54 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 708C2129C69 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 26 Jan 2017 17:54:41 -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 zyGwjuiSrh8i for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 26 Jan 2017 17:54:39 -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 B314A129C62 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 26 Jan 2017 17:54:39 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cWvhO-0001Yf-Bf for ietf-http-wg-dist@listhub.w3.org; Fri, 27 Jan 2017 01:51:34 +0000
Resent-Date: Fri, 27 Jan 2017 01:51:34 +0000
Resent-Message-Id: <E1cWvhO-0001Yf-Bf@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 1cWvhG-0001Vb-Mn for ietf-http-wg@listhub.w3.org; Fri, 27 Jan 2017 01:51:26 +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 1cWvgg-0000cl-H7 for ietf-http-wg@w3.org; Fri, 27 Jan 2017 01:51:21 +0000
X-IronPort-AV: E=Sophos;i="5.33,292,1477918800"; d="scan'208";a="19437260"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 27 Jan 2017 12:50:17 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8420"; a="291004500"
Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbni.tcif.telstra.com.au with ESMTP; 27 Jan 2017 12:50:17 +1100
Received: from wsapp5870.srv.dir.telstra.com (10.75.139.12) by wsmsg3756.srv.dir.telstra.com (172.49.40.84) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 27 Jan 2017 12:50:17 +1100
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5870.srv.dir.telstra.com (10.75.139.12) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 27 Jan 2017 12:50:17 +1100
Received: from AUS01-SY3-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; Fri, 27 Jan 2017 12:50:16 +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=1Dbqlyxo2jQ3fGeXqy4X2zEkOH96d5yqjrs71xsWVzg=; b=LSlvGhNhvWVJ/K6+wo8n+tW2eNscXXEdqnt7hxrhCn5ivFKA7sgLn1GFzagAuTca3LRKU8C9i47MCZm91IghTUnT9OYt/dWo7AdnvbgDZx7QfbOFoJgp/crXPShF2p0Xf7PoaKqdoIAHw7PZjq4AIJyw0fdi+YnkEIbLLxW6vCc=
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; Fri, 27 Jan 2017 01:50:15 +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; Fri, 27 Jan 2017 01:50:15 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: aes128gcm: why verify padding?
Thread-Index: AdJvg9D1nChV1RXVTGiVAO+6sRrzlwADDv6AAAAcAeAADb7rAAFW7FVwAAoO2IAACMzpgAAYx0WAAAAn4DAAZJKWgAAzIAMQ
Date: Fri, 27 Jan 2017 01:50:15 +0000
Message-ID: <SYXPR01MB1615C769ADDAF813BB32A65DE5760@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> <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>
In-Reply-To: <CABkgnnWoSWCeV_TUwDY1J00ivY0TDgU_9NhiSWZpM4_F6XAYfA@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.185.254]
x-ms-office365-filtering-correlation-id: d6d05f52-07b3-404e-2f2c-08d44656d750
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1616;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1616; 7:vln7E9qF+qIn2VGT0TDLPF9XRjrWgp2jqajrzIKuAqRwTQ9MCN5i0iOYi0csl1xbk/veK1rK6j5wTa4x85uTo9ARrv5ch9ziPDcgahTIojXVQ8ythMXeMX1hCNktd6NFaRFh+iDsP+sEuzkSJXG6bK3FXbGtEiRZ5YG+wzRb6pcY+JxzN6iwAxWqZ8hmt+HDlHAkkVFOVzuWFuPrO54b4z5adAjdiEtYd4VZ9t2J2C3tvdaiRntdiV8yiekZX6eSejbD2AWl1Q9nI6/f3YA9Tx2+dOpnVlxvyQfJYWN53s650p1fi74Dz7FYyCbDFp0WScgawT/TQE7UZw8BFP7u1Cj5si3t5FH8Tv3tEcWjhqOzd9SHgBluWmULuUgapkDa8iUBsfkwUApNfb3YSUqt7fpxHhQ/dtUhHXPB3r8cfapcF1CVv7yKs8VTnGjORwe9qHO/n4yoqc/hKOQGSeg2YA==
x-microsoft-antispam-prvs: <SYXPR01MB161690EF3ECD2B239E794C5EE5760@SYXPR01MB1616.ausprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(6042181); SRVR:SYXPR01MB1616; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1616;
x-forefront-prvs: 0200DDA8BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(51444003)(199003)(7696004)(101416001)(2900100001)(81166006)(6916009)(15650500001)(2906002)(33656002)(8676002)(92566002)(5660300001)(93886004)(68736007)(53936002)(122556002)(3660700001)(8936002)(54356999)(81156014)(9686003)(105586002)(77096006)(229853002)(6506006)(39060400001)(55016002)(86362001)(6436002)(25786008)(99286003)(76176999)(54906002)(305945005)(38730400001)(50986999)(74316002)(6116002)(3846002)(2950100002)(4326007)(3280700002)(102836003)(42882006)(97736004)(66066001)(189998001)(7736002)(110136003)(106356001); 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: 27 Jan 2017 01:50:15.8319 (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.82.208; envelope-from=James.H.Manger@team.telstra.com; helo=ipxcno.tcif.telstra.com.au
X-W3C-Hub-Spam-Status: No, score=-0.7
X-W3C-Hub-Spam-Report: RCVD_IN_DNSWL_LOW=-0.7, TIME_LIMIT_EXCEEDED=0
X-W3C-Scan-Sig: mimas.w3.org 1cWvgg-0000cl-H7 eb094d8dada7edcc5dc5d3ee971b4454
X-Original-To: ietf-http-wg@w3.org
Subject: RE: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/SYXPR01MB1615C769ADDAF813BB32A65DE5760@SYXPR01MB1615.ausprd01.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33385
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>
>> If we go with this approach, we should also distinguish the 1st record. For instance, for the end-of-padding byte: > I think that might be going too far. Truncating the first record requires that you are able to find an input to HKDF that provides the same key, and a nonce that has just the lower bit flipped (you can truncate more with higher probability). That requires several preimage attacks on SHA-256 in series. Mostly though, marking the start also increases complexity. I think that it's enough to say 0x01 = keep going, 0x02 = all done. I agree that Start-or-middle vs End is enough in this case due to the KDF. 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. -- James Manger
- aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Ilari Liusvaara
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Ilari Liusvaara
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James