Re: [TLS] padding

Dave Garrett <> Sun, 23 August 2015 00:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 490B31A701A for <>; Sat, 22 Aug 2015 17:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yx4r7ahG0OcB for <>; Sat, 22 Aug 2015 17:28:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5B8C1A7017 for <>; Sat, 22 Aug 2015 17:28:48 -0700 (PDT)
Received: by ykll84 with SMTP id l84so103935812ykl.0 for <>; Sat, 22 Aug 2015 17:28:48 -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=aAULMqjmU/5LjEZL1QzcP7OF8BeNA+Q2IGCaMAmntWk=; b=E8Y2/+0hPue2ZpFC24jU995pf7ykCNCZVKSg0TURw2ZJsKUXwN0M8LRvhu8hy00C/q lUWfLKZvmd0SrRXjSam8DhBXCk/6sZPM0+ChK1TWYpRsbtuTrzXfm/UBOy6Fw5V2ETE6 SvITZiYH2Hf7fmP5+1U2BXI+MDwVDJOoyCYvY00N1bQtGlu7VKKcjQnk7Ksyo9erDZzZ ldrz8faUseX6djclhrYskFrnT9Fg8AAUajDWKngyDv/oAIteraRQ6DTpVVoZLjiBr1Ku 6UNqLs2HEEszem5F36I56x+wkjeQa6l/yTuNpGFxJNS4oBqe1PlQRV34aYMv6mBPI/4j jaAA==
X-Received: by with SMTP id 2mr22023945ykj.20.1440289728025; Sat, 22 Aug 2015 17:28:48 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id g197sm12419121ywb.46.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 22 Aug 2015 17:28:47 -0700 (PDT)
From: Dave Garrett <>
To: Russ Housley <>
Date: Sat, 22 Aug 2015 20:28:45 -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: quoted-printable
Message-Id: <>
Archived-At: <>
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: Sun, 23 Aug 2015 00:28:50 -0000

On Saturday, August 22, 2015 03:36:21 pm Russ Housley wrote:
> > 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.
> 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?

Toggling solves the undesired bandwidth use concern stated by Tom by making it fully optional on both sides. The even simpler route of just having to check if there's bytes in the encrypted fragment other than the payload would avoid a little bit of complexity, but with no way for an endpoint to say no to increased bandwidth usage that it doesn't want to or can't handle. Given this constraint, I'd favor either easily toggleable or always-on, rather than a middle-ground where implementations won't know what they're going to get and can't do anything about it.

A footnote: Negotiating via an extension is probably not a good idea because client extensions will generally be in the clear. That's why I suggest a simple message instead. (there's no need to pad the cleartext hello, so it's fine to wait until record protection is available) Note that I don't think allowing this to be decided after the handshake is a good idea.

A more generalized way to handle throttling padding would be to set a low default and require each endpoint to send a message with a different value, in max bytes per record (or second, or both) of padding permitted, in order to use a different amount. Each endpoint could easily arbitrarily throttle its downstream padding bandwidth independently, if need be.

I'm curious as to how much of a range would actually be useful, though. For actually good protection, you'd really want to pick a stable bandwidth and essentially hold it; keep up/download rates constant or following some consistent pattern with a combination of possibly throttled data and padding such that the data length and time is completely protected and the stream is 100% opaque to an observer. I wouldn't expect this to be all that popular, though, as it would be a bandwidth hog in many cases. A middle-ground might involve also specifying a max bytes allowed in between data bursts to hide the peaks, but now we're getting more complicated than I think we want here if we go any further. (and beyond what I know anything about) The current proposal says that padding algorithms are outside of the scope here, but I think adding this as a built-in feature without coming up with some easily usable default (even if not particularly advanced) is a mistake that will cause this feature to be largely unused.