IETF Logo Mail Archive

[TLS] proposal to encrypt ContentType for TLS 1.3

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 01 July 2014 22:09 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 0D4D91A041C for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 15:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mu3yf5ebU1Ru for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 15:09:49 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20FC71A00DB for <tls@ietf.org>; Tue, 1 Jul 2014 15:09:48 -0700 (PDT)
Received: from [192.168.13.159] (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 8D925F984 for <tls@ietf.org>; Tue, 1 Jul 2014 18:09:43 -0400 (EDT)
Message-ID: <53B331A5.2040908@fifthhorseman.net>
Date: Tue, 01 Jul 2014 18:09:41 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
To: IETF TLS WG <tls@ietf.org>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="NP7HMslag5Uj8txuo5IJ5cdbBfCI8PxIE"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v7xEd3n652Uh4OOoTMFCXbFOSxs
Subject: [TLS] proposal to encrypt ContentType for TLS 1.3
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: <http://www.ietf.org/mail-archive/web/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, 01 Jul 2014 22:09:51 -0000

hey folks--

i just opened a pull request to propose that the TLS ContentType (when
actually using a proper cipher) should itself be encrypted, rather than
in the clear:

 https://github.com/tlswg/tls13-spec/pull/51

As the main commit in this request says:

>     Move Content Type inside encryption
> 
>     Previous versions of TLS have left the Content Type in the clear
>     without justifying the exposure of this piece of information.
>     
>     This change moves the Content Type inside the encryption to protect
>     its confidentiality.
>     
>     For backward compatibility during the initial handshake negotiation,
>     we need to keep the type field at its original location on the wire
>     for cleartext packets.  This means redefining the NULL_NULL case to
>     not simply be an pseudo-cipher that implements the identity
>     transformation, but to explicitly state it as sending the TLSPlaintext
>     struct directly over the wire.

I'd be interested in feedback on this suggestion.

Having the content-type encrypted would mean that TLS alerts,
handshakes, and application data would be indistinguishable from one
another to an observer, once a ChangeCipherSpec had taken place.

This also opens the way to consider the creation of other content types
(e.g. "padded application data") without having to decide whether the
exposure of a novel ContentType to an observer is itself a risk.

If this change is made, it's also relatively easy to just drop the TLS
version field for each encrypted TLS record layer fragment.

All the best,

	--dkg

v2.23.0 | Report a Bug | By Email