Re: [TLS] encrypted content type and padding

Dave Garrett <> Mon, 21 September 2015 17:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4933A1ACDC2 for <>; Mon, 21 Sep 2015 10:36:15 -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 LEmddTdKIIJe for <>; Mon, 21 Sep 2015 10:36:14 -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 D33EE1ACDC0 for <>; Mon, 21 Sep 2015 10:36:13 -0700 (PDT)
Received: by ykdt18 with SMTP id t18so109516114ykd.3 for <>; Mon, 21 Sep 2015 10:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=RPznh5FWg2+GUUGHYQaabspSQTO9nQIi3ai36He+7vU=; b=yfJsyKqyKumyMUzs43Vh60eiKkbDPlI87QT7nR8Qk7VuWwEeZseqghwCbFI5O4Se8Y laauWGLs837Vb6l3cuBNDaBIz2vRe20TDqBghhmtDnRm7BG6RmQgnIejvrYdpbu30PAt dV/fj5+g5lnyGU63T00oy0JGKZ8LNXsarOT2DVrWjlJyhr/8aisxM+H6u4JACtpUoZCk PrbxMZyjkMs7dWwNn0VJ5pwVfbolAFxjse7G+bEWbXMfpd+nrPmtY/ZPnuWo6xQeNNyd si48BukofB0h5F43F0XCfOU0Pay6erLuBdYUJCrBEukLMBpAGGo0XsttmXF/0p2oJxm/ x0tQ==
X-Received: by with SMTP id x8mr17407919ywc.44.1442856973089; Mon, 21 Sep 2015 10:36:13 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id j1sm16014472ywj.10.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Sep 2015 10:36:12 -0700 (PDT)
From: Dave Garrett <>
To:, Daniel Kahn Gillmor <>
Date: Mon, 21 Sep 2015 13:36:10 -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: <>
Subject: Re: [TLS] encrypted content type and 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, 21 Sep 2015 17:36:15 -0000

On Monday, September 21, 2015 03:02:47 am Daniel Kahn Gillmor wrote:
> encrypted content type:
> -----------------------

Basing the padding PR(s) on top of this might be a good idea, seeing as it's desired to do this correctly.

One thought about doing this with a separate record type, though. It might be better to generalize it by reserving the top bit in the type as a padding flag, thus allowing padding variants of all other types. Record type values would just be the unpadded value plus 128. Implementations could check for padding by simply ANDing a mask to check for the flag. The remaining 7 bits is plenty for the record types field. This could be used for the handshake messages instead of adding a separate handshake padding message. No special type value registration would be needed to add any future padded types.

> i personally prefer PR #249 because it is more inline with the
> traditional layout of TLS data elements, and lacks additional risk of
> timing differences.  Its main downside is its inability to pad by
> anything less than two octets, which slightly complicates calculations
> of how much to pad when padding algorithmically.

I agree. Simpler is probably better here.