[TLS] Why is padding still actively being used?

Jeffrey Walton <noloader@gmail.com> Sun, 17 May 2015 00:24 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 18B611A8866 for <tls@ietfa.amsl.com>; Sat, 16 May 2015 17:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7iMfKxiHlKCj for <tls@ietfa.amsl.com>; Sat, 16 May 2015 17:24:52 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6371A8871 for <tls@ietf.org>; Sat, 16 May 2015 17:24:52 -0700 (PDT)
Received: by igbyr2 with SMTP id yr2so23857615igb.0 for <tls@ietf.org>; Sat, 16 May 2015 17:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=3DBXetVFmii4X6rSn5B1KrQGXOOxtfZt5tin/e4imGs=; b=E9v4FKS/PZFQsa1xlFA2Pd7ygwTKeCl9rKDUZH86nUuYtMdInfIoCgiwqEdQzlUF/o Zz+ph8ANCoIH7yIyGIngDSNjk5VrETKRgebZ1twrXUMcEgbNKYbOjPnXgS/zsVHtsTyn IWsK+Q7i5jmGocdwio2JNQQmFKtCfUxSE1Rq/lxkUzJY5M8EGSRQaGkLu+APkBLL/piw brNhl/VI9qOejWhdA05/2iskJgOJarh0jIHCi2Ga/t+GTIxSqpJmWH6wQcN5zsIdMmcd yBgb9uUZd1WI7o3NSBkNJj/Zp9V2Ou4rgNqaf+8PXp7FwLpef1ODDaUcEPKg3kAau0L3 50Gg==
MIME-Version: 1.0
X-Received: by with SMTP id a4mr6606551igx.34.1431822292227; Sat, 16 May 2015 17:24:52 -0700 (PDT)
Received: by with HTTP; Sat, 16 May 2015 17:24:52 -0700 (PDT)
Date: Sat, 16 May 2015 20:24:52 -0400
Message-ID: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PvqLR89xAEn61GA9pLVf0O_V0X8>
Subject: [TLS] Why is padding still actively being used?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 May 2015 00:24:54 -0000

Integrated Encryption Schemes, like ECIES and DHAES, don't pad in the
Data Encapsulation Mechanism (DEM) or Key Encapsulation Mechanism
(KEM). In the case of a KEM, they fill the parameter to the size of
the underlying field, and then use a derivation function to digest it.

Removing the padding simplifies the proofs and removes the oracles
related to the padding.

When possible, why does TLS still pad and backfill with 0's rather
than filling to the underlying field size and/or digesting?

(And I understand block ciphers need padding, so sometimes padding is
required in the IES equivalent of a DEM).