Re: [TLS] padding

Russ Housley <housley@vigilsec.com> Sat, 22 August 2015 19:37 UTC

Return-Path: <housley@vigilsec.com>
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 762561B2C9F for <tls@ietfa.amsl.com>; Sat, 22 Aug 2015 12:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level:
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] 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 C8_svWrOVaoI for <tls@ietfa.amsl.com>; Sat, 22 Aug 2015 12:37:04 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 04B311ACD47 for <tls@ietf.org>; Sat, 22 Aug 2015 12:37:04 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E7AA5F24129; Sat, 22 Aug 2015 15:36:52 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 3lCssatQ7xkE; Sat, 22 Aug 2015 15:35:35 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 323C4F24128; Sat, 22 Aug 2015 15:36:32 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <201508211832.14227.davemgarrett@gmail.com>
Date: Sat, 22 Aug 2015 15:36:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5E97433-3633-4C4B-B508-2B49F97A9AD7@vigilsec.com>
References: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com> <201505171532.31109.davemgarrett@gmail.com> <CA+cU71knu=WCZTpOvMXE455TevfS_8Oa=j-3vpQ=0Nze6POpQA@mail.gmail.com> <201508211832.14227.davemgarrett@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_L_IoZ850QbNLWVRvOrFAvB9Hus>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] padding
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 22 Aug 2015 19:37:05 -0000

Dave:

> On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
>> On 17 May 2015 at 14:32, Dave Garrett <davemgarrett@gmail.com> wrote:
>>> Is it really necessary to have a separate application_data_padded content type? It'd be simpler to just keep using existing types but amend it with a padding field and require it always be used at minimum to pad up to the nearest multiple of N-bytes. (something low for the default) Additional padding would be optional, but all data would get some minimum.
>> 
>> That was the first proposal, but the extra bytes on every message for
>> people who weren't using padding were deemed to be prohibitive.
> 
> Wouldn't it be simpler to just have an optional padding vector that exists only if padding is negotiated? (we already have one optional field with extensions in the hello messages)
> 
> A simple method to negotiate would be to add a new HandshakeType with a couple flags, one to indicate that the endpoint will be sending padded messages and another to indicate that it's willing to receive padded messages. Endpoints could declare padding with this message and use it until its peer sends a message requesting otherwise. This sort of scenario would have the additional benefit of not stating the existence of padding in the clear.

I like the idea that the presence or absence of padding in the ciphertext is hidden in your proposal.  Is there really an need to toggle it on and off?

Russ