Re: [TLS] padding

Tom Ritter <> Mon, 24 August 2015 23:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 031611B2B0E for <>; Mon, 24 Aug 2015 16:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YKHswgYsmery for <>; Mon, 24 Aug 2015 16:22:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 247F21ACEEA for <>; Mon, 24 Aug 2015 16:22:32 -0700 (PDT)
Received: by iodv127 with SMTP id v127so167137915iod.3 for <>; Mon, 24 Aug 2015 16:22:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ocwg9fHUrL9cI3f7HEcEoyKDtolzRkoqgoC0N9DIySk=; b=B82/7vUzrAuQ3HM1HUSTgsgGynL8emnu3zxd1dO3NcWAdFnBOqIxifZHDGq34mnYp8 NNuRWq5eZ0u2cv7F4wUCcunVSYLNd3oFrLfGWyFQb7mWoLXFTdR8s6nuuJc+nHe6odxi wfkwSJs7OpDW2AuBIlmuEtnt5pB3l741rCSf0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ocwg9fHUrL9cI3f7HEcEoyKDtolzRkoqgoC0N9DIySk=; b=Eh3BKtdheEPyTIOAePcL07VIQBK9396UP6kyF6pMUDiGmfkr+IzY7Zv+LW5Y9mPLHk NMhbPDN2ceKmF+TTI4BxRzCKDqMi+GWWEanuyO/IxgJh2s0XTZ2D8IVzf+QIwG0TCGd/ IlOYzlRx6JuQQdyJXEsbrYUTPX6/xhSnIT+IJ8n0WkCgXgPXPJQWpQ6NP/o4RmMqcGMw J8BX1742ef1FjZ4phOoqhVkwX4m1/vnRJCeDHc7l5k1pgR+BAZOijJqpD6W0/ZefDE2a mqq95RF2RsWckK5fXfNriAgOeI7SnCywCkk6URDfNf/LndY53H0AcnyQH3wpyr9qTx9I hT6Q==
X-Gm-Message-State: ALoCoQkI6Gl4W8hyP3FliB5jjDJyk6qWRvbRXd9hk4lv0A1wSZWWK6jePiegPkuF2s6za3QUtA9r
X-Received: by with SMTP id n40mr24321969ioi.47.1440458551346; Mon, 24 Aug 2015 16:22:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Aug 2015 16:22:11 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Tom Ritter <>
Date: Mon, 24 Aug 2015 18:22:11 -0500
Message-ID: <>
To: Dave Garrett <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Mon, 24 Aug 2015 23:22:34 -0000

On 22 August 2015 at 19:28, Dave Garrett <> wrote:
> 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 have a not-very-hidden motive in not having it be negotiable: I want
to enable clients to want to send padding be able to do so to any
server, even if that server does not want to pad.  (They can just
discard.)  If it's negotiated, the server may say "I don't support
padding" and clients who want to use it out out of luck.

I do like solutions where the use or non-use of padding is hidden, but
I think in many cases it will be obvious, so the above goal comes
before this goal for me.  I don't believe the topic of encrypting the
content type is completely resolved, but that is a separate proposal:

> 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.

In general, developing good padding approaches is relatively easy for
well defined application protocols, and difficult for extremely
generic ones like "Browsing the Internet".  If one was developing an
application for twitter, google maps, XMPP chat - developing a good
padding mechanism to hide specific actions or data would not have the
same issues.

There's been a number of padding strategies developed by academic
researchers studying traffic correlation/confirmation attacks - I
don't expect any of them is drop-in-good-enough for a generic browser
implementation... but it would be _amazing_ if browser vendors enabled
browser extension authors to choose the padding strategy for
individual origins.  Then we can crowdsource the effort.