Re: [TLS] Why is padding still actively being used?

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sun, 17 May 2015 05:29 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FAC1A897A for <tls@ietfa.amsl.com>; Sat, 16 May 2015 22:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 koFQiZuAus8p for <tls@ietfa.amsl.com>; Sat, 16 May 2015 22:29:39 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F0E1A888F for <tls@ietf.org>; Sat, 16 May 2015 22:29:38 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8414F817E7; Sun, 17 May 2015 08:29:36 +0300 (EEST)
Date: Sun, 17 May 2015 08:29:36 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Jeffrey Walton <noloader@gmail.com>
Message-ID: <20150517052936.GA26393@LK-Perkele-VII>
References: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/p8Hfy2Wypfva00V5g3fVuYuHCWs>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Why is padding still actively being used?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 05:29:42 -0000

On Sat, May 16, 2015 at 08:24:52PM -0400, Jeffrey Walton wrote:
> 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?

Are you talking about leading zero stripping in Diffie-Hellman key
exchange?

I think many bignum libs perform that kind of thing, which is a
good source of bugs (especially in big-endian).

However, if using dedicated arithmetic (generic bignums are not
safe) for fields available in TLS 1.3, that kind of stripping is
just extra complexity and source of bugs.


Thinking about padding, I think there should be some sort of
payload padding under AE, fro those applications that want to hide
lengths of messages.

In TLS 1.2, it could easily be added as new "compression" mechanism,
but those are not supported in TLS 1.3.


-Ilari