Re: aes128gcm: why verify padding?

Martin Thomson <martin.thomson@gmail.com> Mon, 16 January 2017 00:36 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 E9531127058 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 15 Jan 2017 16:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.72
X-Spam-Level:
X-Spam-Status: No, score=-9.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, RCVD_IN_SORBS_SPAM=0.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 (2048-bit key) header.d=gmail.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 kp817i156RP8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 15 Jan 2017 16:35: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 3E82E1289B0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 15 Jan 2017 16:35: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 1cSvEf-00055e-1I for ietf-http-wg-dist@listhub.w3.org; Mon, 16 Jan 2017 00:33:21 +0000
Resent-Date: Mon, 16 Jan 2017 00:33:21 +0000
Resent-Message-Id: <E1cSvEf-00055e-1I@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 <martin.thomson@gmail.com>) id 1cSvEb-00054I-TW for ietf-http-wg@listhub.w3.org; Mon, 16 Jan 2017 00:33:17 +0000
Received: from mail-qt0-f172.google.com ([209.85.216.172]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <martin.thomson@gmail.com>) id 1cSvEU-0004cN-VM for ietf-http-wg@w3.org; Mon, 16 Jan 2017 00:33:12 +0000
Received: by mail-qt0-f172.google.com with SMTP id x49so91653249qtc.2 for <ietf-http-wg@w3.org>; Sun, 15 Jan 2017 16:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Mhm1OjeP6BQWDKgBea9AsRTfO0JVDZP91FETy+CykeA=; b=e14IU+GxI0phS6FF6Ix6Q7AAJWNjwbm1UBm6UX7NXqABjsxsk3Cb32MtqVfOJzXyIU sfamWwxBs4xtEYjoOe200S6BbzPEscdacRbpOf+odxBIoZxiWUo2vVrmSQkZvStJRhlA Yrl3Z1+qbGafmYlnGkxgC0LhUUYFg6WV5WsH+NB+IrHBrYQqexrdqpG5YNKMrwFOmz80 M8YCmFifURxnTL6iR8oVaKwBEYKuleFxc6J20EHUEkK9Vyf5NzmbjZS23RgFvvbottmo VhLhDO1L/aQXmtcjBqMPjSw7hg+uRh3BUvCSGX6qxjlDd9cMYG1YNiEUrFZ1lO9nT1M3 jV9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Mhm1OjeP6BQWDKgBea9AsRTfO0JVDZP91FETy+CykeA=; b=LVrS7ZaaLyoFHLkY7/zk3jy7E75uaPE6nICHNE+QJc3bzJWePhs3LP0Tj3Wkih4D3J +/6mVBwn8oCwOr9oGgg8qPVsXr0zJUTuGwmcYYRCWg3R4inNvg3flgMoeilOJqwJyuxz X8Saio1CcOE/McpyrlQhPRRRrv6fHbbsvEUn7Xr9FqRfLwznR23mQUBheS94l/puv75x K00SOH+GSa3MOU+gTtg8+zweMmYgzjJ642xX1GDuKhyQxppl1+JfaKroGe3vHdCf57Np G8pG7Y/5F5JcY6HubDj2pSYbWgsovXTQXDK+RSeB0EBhG6czJpG5uHY4S+8ZucHAafnc vFuw==
X-Gm-Message-State: AIkVDXIvT7FBIEXz9x7wLNAp2ndqsvx/8yL0KrjvWZJvxd06jxmR97/+4z145AKVKwVP4OV5Y2CJqJH76cMVWg==
X-Received: by 10.200.49.249 with SMTP id i54mr29278936qte.3.1484526764478; Sun, 15 Jan 2017 16:32:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 15 Jan 2017 16:32:43 -0800 (PST)
In-Reply-To: <SYXPR01MB161520224A59CDCE0D433A2CE57A0@SYXPR01MB1615.ausprd01.prod.outlook.com>
References: <SYXPR01MB161520224A59CDCE0D433A2CE57A0@SYXPR01MB1615.ausprd01.prod.outlook.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 16 Jan 2017 13:32:43 +1300
Message-ID: <CABkgnnUo-tf69AzJC=OUy2rjDZwedTd5Ua9mhOiJBqaA0VKrYw@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.216.172; envelope-from=martin.thomson@gmail.com; helo=mail-qt0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-0.830, BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cSvEU-0004cN-VM a808c72d4858adeba52419f4ac6d9d0b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/CABkgnnUo-tf69AzJC=OUy2rjDZwedTd5Ua9mhOiJBqaA0VKrYw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33284
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.

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
>
>