Re: [TLS] Encryption of TLS 1.3 content type

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 28 July 2014 13:58 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 8D8161B27F9 for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 06:58:00 -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 kJYJq6YrQ_dW for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 06:57:55 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B21A0452 for <tls@ietf.org>; Mon, 28 Jul 2014 06:57:55 -0700 (PDT)
Received: from [10.70.10.76] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A2852F984 for <tls@ietf.org>; Mon, 28 Jul 2014 09:57:52 -0400 (EDT)
Message-ID: <53D656D3.5050307@fifthhorseman.net>
Date: Mon, 28 Jul 2014 09:57:39 -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: "<tls@ietf.org>" <tls@ietf.org>
References: <DD255E31-FA87-40CE-AF13-0F43A7DD54CF@cisco.com> <CACsn0cnt-ry182AjOyTTZGteifs7VyRPYHaj-xDCBOf0D53w9A@mail.gmail.com> <CAAF6GDfK7awipoMT_PPyKnTe-fF1=KY1Be8kUMSYrXN0Wzb=tg@mail.gmail.com> <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fLlD9xjjqKreUkBCRMo9qI1ukDv5LhUsp"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IxNikQDxyMigzH9kYJHS0jn4Yrw
Subject: Re: [TLS] Encryption of TLS 1.3 content type
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: Mon, 28 Jul 2014 13:58:00 -0000

On 07/28/2014 04:55 AM, Nikos Mavrogiannopoulos wrote:
> Unless TLS 1.3 intended to include a length hiding mechanism
> I see this change as unnecessary and I agree with Watson on that.

One of the motivations to support this change is due to the possibility
of length-hiding within TLS (which might be indicated by a new
content-type), as well as leaving the door open to other future content
types that might or might not be sensitive.  It was a design error to
ever leave this information in the clear in the first place, afaict.  We
should fix it.

If we have to throw a dummy byte (or two, if we need to include the
version) per (D)TLS record to appease middleboxes, we can do that, but
that should be strictly for the sake of working around the ossified
network stack.

	--dkg