Re: [TLS] the perils of padding

Benjamin Kaduk <bkaduk@akamai.com> Fri, 07 April 2017 17:28 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5A0129576 for <tls@ietfa.amsl.com>; Fri, 7 Apr 2017 10:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 JgOZlUXsD0u9 for <tls@ietfa.amsl.com>; Fri, 7 Apr 2017 10:28:22 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id E74C912956A for <tls@ietf.org>; Fri, 7 Apr 2017 10:28:21 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5207416C912; Fri, 7 Apr 2017 17:28:21 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 3C26016C90D; Fri, 7 Apr 2017 17:28:21 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491586101; bh=TaAxl81V+r4uzsDDfpsBqxa/wD9Cv2LM2qzAC2GkY4g=; l=2525; h=To:References:Cc:From:Date:In-Reply-To:From; b=p8RdRZqkrW6/GuSw5dXuS+a6wr9XUV1QNmRVLdK7eT9axdDzeaacLqvvmcZauc+n9 WQ3OO/7ZLoBWr2F4wmxnA4eXXD3dFOGMVfIcul4YB2h3TcyTGTOgeQto7vHqB0FBLl 2MLPhXdRUO5F3YTieYAws1ocUx8RZKLY+kIqry4g=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DE5501E08F; Fri, 7 Apr 2017 17:28:20 +0000 (GMT)
To: Nico Williams <nico@cryptonector.com>
References: <e0714b0b-edc9-16e0-1448-c33b5a6f0fa5@akamai.com> <20170407172534.GA5654@localhost>
Cc: "<tls@ietf.org>" <tls@ietf.org>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <b0f423ff-5f93-84d8-8814-4d0e209922f4@akamai.com>
Date: Fri, 07 Apr 2017 12:28:20 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170407172534.GA5654@localhost>
Content-Type: multipart/alternative; boundary="------------5EDF08FBCE241757D177BD2B"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pv5rR_gzp96D27JWZ_sD_CZBkEo>
Subject: Re: [TLS] the perils of padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Apr 2017 17:28:24 -0000

On 04/07/2017 12:25 PM, Nico Williams wrote:
> On Fri, Apr 07, 2017 at 12:05:42PM -0500, Benjamin Kaduk wrote:
>> One simple and easy option is to have a new extension to indicate the
>> maximum consecutive padding that will be accepted by an endpoint, and
>> abort the connection if too much padding is received in a row without
>> any non-padding content.  But that might be too complicated, and we
>> could just note that implementations may get grumpy if they see too much
>> padding and abort the connection; peers are basically allowed to abort
>> the connection at will already, so it's not really a new thing.
> Or, you know, just close the connection.  Give them a fatal record to
> tell them why.  No need to tell them up fron how much naughtiness you'll
> allow.

Right.  But it might be worth adding to the list of things to check
about your implementation in Appendix <mumble>.

-Ben