[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 [127.0.0.1]) 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-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 EGMVNAbNaQjB for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 00:02:50 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) 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 [73.169.183.211]) 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: ----------------------- https://github.com/tlswg/tls13-spec/pull/51 This should be uncontroversial, and just needed freshening against the current draft. padding: -------- 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: https://github.com/tlswg/tls13-spec/pull/249 But if anyone is interested, i've also mocked up using a "padding is all 0x00 up to the first 0x01" approach: https://github.com/tlswg/tls13-spec/pull/250 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, --dkg
- [TLS] encrypted content type and padding Daniel Kahn Gillmor
- Re: [TLS] encrypted content type and padding Jeffrey Walton
- Re: [TLS] encrypted content type and padding Watson Ladd
- Re: [TLS] encrypted content type and padding Daniel Kahn Gillmor
- Re: [TLS] encrypted content type and padding Dave Garrett