Re: [TLS] padding

Yoav Nir <ynir.ietf@gmail.com> Tue, 25 August 2015 08:47 UTC

Return-Path: <ynir.ietf@gmail.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 911881A875C for <tls@ietfa.amsl.com>; Tue, 25 Aug 2015 01:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JraugxnsVpy for <tls@ietfa.amsl.com>; Tue, 25 Aug 2015 01:47:35 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49831A1BC2 for <tls@ietf.org>; Tue, 25 Aug 2015 01:47:34 -0700 (PDT)
Received: by wicja10 with SMTP id ja10so7913114wic.1 for <tls@ietf.org>; Tue, 25 Aug 2015 01:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pc3Jp9sQG+rVIDEV6XcNQybXQD7tg5enzPpJbEBrA74=; b=bNC8s5H/55Tgg4/lZZQ8RCFRklfucPJrYbeJevcAWEBm/yzESrWiecco5WkTFho4uR UXbGzo2KZ7Asb9THRI3URoC1aZ+32cec6zK8D0NK0TxmYKJuPe9G+3Z0HkI/vPVm0OxS PYOmAUpN/b6baowLMYiZa0EHsBba6dvYoeUCHYv1M9FmUkIj0kuKs6e2caeQ4gqOkMZ1 cGAkzVAd2BvHb9xOunwTu9aqR3UhSJ5xQQMc67LQ4hXyFe8w3J/1v8GWb6cQfX+yAVNA R0ke7a1EMGTqbMCSUqBqWLfrpEZlMpy1lmJKSeUcCsd/cjW3PBYvoaKjDWMoMrcvZO4m PImw==
X-Received: by 10.194.201.71 with SMTP id jy7mr48994988wjc.93.1440492453550; Tue, 25 Aug 2015 01:47:33 -0700 (PDT)
Received: from [172.24.248.148] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id eu2sm1528806wic.8.2015.08.25.01.47.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 01:47:33 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CA+cU71kS=x7_hVRXb8Q8m=DmqMaM65GaEn1SnzH_fQHP9mzyqA@mail.gmail.com>
Date: Tue, 25 Aug 2015 11:47:29 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E487941B-E099-4497-81FB-2F5AD3E228F6@gmail.com>
References: <CAH8yC8nQKzht4g6+FwvmN1ULCz3a+2j=0UF4h=8h71XbcVjFDQ@mail.gmail.com> <201508211832.14227.davemgarrett@gmail.com> <A5E97433-3633-4C4B-B508-2B49F97A9AD7@vigilsec.com> <201508222028.46145.davemgarrett@gmail.com> <CA+cU71kS=x7_hVRXb8Q8m=DmqMaM65GaEn1SnzH_fQHP9mzyqA@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QPVfMSRbHQ8UjKohqqTCS79Vgz0>
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: Tue, 25 Aug 2015 08:47:36 -0000

> On Aug 25, 2015, at 2:22 AM, Tom Ritter <tom@ritter.vg> wrote:
> 
> On 22 August 2015 at 19:28, Dave Garrett <davemgarrett@gmail.com> 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’m not sure having one side send a continuous stream of large record buys you much if the other side doesn’t. Suppose an HTTPS server has 100 resources, each with a different size, it won’t help if the client obscures the identity of the resource it’s asking for if the resource can be identified by its size. Same goes for the existence of traffic. If the server stays quiet until there’s an actual request, the client’s continuous stream of padding-only records is just wasted effort.

IMO this is an argument for negotiation, although even with negotiation we can never be assured that the other side is doing TFC well. 

Yoav