[TLS] encrypted content type and padding

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 21 September 2015 07:02 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E58901A1B2E for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 00:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EGMVNAbNaQjB for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 00:02:50 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org []) by ietfa.amsl.com (Postfix) with ESMTP id 0E81D1A1B29 for <tls@ietf.org>; Mon, 21 Sep 2015 00:02:49 -0700 (PDT)
Received: from fifthhorseman.net (c-73-169-183-211.hsd1.wa.comcast.net []) by che.mayfirst.org (Postfix) with ESMTPSA id 318F7F984 for <tls@ietf.org>; Mon, 21 Sep 2015 03:02:48 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 7CFD920CD0; Mon, 21 Sep 2015 03:02:47 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: IETF TLS Working Group <tls@ietf.org>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Mon, 21 Sep 2015 00:02:47 -0700
Message-ID: <87bncw1ch4.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gEng4suoUZKkWV4ogZEuplMAFXw>
Subject: [TLS] encrypted content type and 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: Mon, 21 Sep 2015 07:02:52 -0000

Hey TLS folks--

apologies for the delay in sending these pull requests.

encrypted content type:


This should be uncontroversial, and just needed freshening against the
current draft.


We're now proposing that handshake padding should be offered by
introducing a new HandshakePadding message.  I've avoided any sort of
padding negotiation in the handshake in favor of making padding always
available in TLS 1.3 and up.  Life is simpler this way.

There are two approaches available for application data padding which we
failed to select from at Prague (possibly because this is a bikeshed).

My preferred approach is to use a standard tls opaque field for
application data padding:


But if anyone is interested, i've also mocked up using a "padding is all
0x00 up to the first 0x01" approach:


This last approach is unlike anything else in TLS data structures, but
it does give the sender the ability to pad with only one octet.

There may be a slight sidechannel difference between offsetting by the
size of the TLS opaque padding object (PR #249) when compared to running
memchr(cleartext, '\001', cleartext_length) (PR #250), but i suspect
that timing difference is small compared to the difference incurred by
whatever is processing the cleartext (though if the cleartext processor
was designed to be constant time itself, the padding timing sidechannel
might be noticable).

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.

See you all in the morning,