Re: [TLS] padding

Dave Garrett <> Fri, 21 August 2015 22:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E1EA91ACEA0 for <>; Fri, 21 Aug 2015 15:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ofi4P9wqslNs for <>; Fri, 21 Aug 2015 15:32:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73BFB1ACE99 for <>; Fri, 21 Aug 2015 15:32:16 -0700 (PDT)
Received: by ykll84 with SMTP id l84so84872900ykl.0 for <>; Fri, 21 Aug 2015 15:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=YrjCusNZdgLr6GawV+U+6iz3d1S07Z+XFYfq770HIMc=; b=NNZfhVn+Hs3EL/SH8Xf9qo5ZY6uNiZ/iobvwE6UoAh4d/WRiZsbA98wwLK5nNkg/as HlS1Cn5IVd06EGM3+eqRt1/Z+NgA1EjyFQJk6dPm9lEJs7x/Dpi8LiJ78gBXfGT6oPKk lrW6UtAEUrtjs+z+RmRpzOWn7SvavCiFeJDwDI3Hj3vSRqbPQTaXHwWQ1k68N/8EJkOz B4miVwPWr55Zj9paoqQJuh87u6H531NMEuEX5ytD+Fw3rdXQGaPXlrucR2oqK0Lzqh74 JXDm3BHFr7Juy30gS0Ljzo43puqvD3yA9OH+QKKCaZzGVeqW2EfrF96HYo1T6N/bHhA6 eQbA==
X-Received: by with SMTP id x68mr15406509ywf.124.1440196335849; Fri, 21 Aug 2015 15:32:15 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id l68sm8868830ywd.49.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 21 Aug 2015 15:32:15 -0700 (PDT)
From: Dave Garrett <>
To: Tom Ritter <>
Date: Fri, 21 Aug 2015 18:32:13 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] padding
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Aug 2015 22:32:18 -0000

On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
> On 17 May 2015 at 14:32, Dave Garrett <> 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.