Re: [TLS] Encryption of TLS 1.3 content type

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 28 July 2014 15:05 UTC

Return-Path: <nmav@redhat.com>
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 C9CC41B2888 for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 08:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 g_Us5c1cyyuM for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 08:05:55 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360C01B2887 for <tls@ietf.org>; Mon, 28 Jul 2014 08:05:55 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6SF5pna005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jul 2014 11:05:52 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6SF5nIg014223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 11:05:51 -0400
Message-ID: <1406559952.7750.14.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Mon, 28 Jul 2014 17:05:52 +0200
In-Reply-To: <53D656D3.5050307@fifthhorseman.net>
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> <53D656D3.5050307@fifthhorseman.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GaJdPgSjMXsopnnpubG-BYYTPKY
Cc: "<tls@ietf.org>" <tls@ietf.org>
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 15:06:00 -0000

On Mon, 2014-07-28 at 09:57 -0400, Daniel Kahn Gillmor wrote:
> 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.

I don't think so. The privacy concerns over the content type are
minuscule(*) and the debugging information provided by them is priceless
to a network engineer.

(*): I understand the trend of encrypt as much as possible -indicated by
the charter entry on handshake protocol and extended here to the record
protocol-, but what is really the threat here?

> 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.

Such moves contribute to the complexity of TLS implementations and I
don't see any immediate privacy enhancement here to justify that (note
that TLS has different goals to TOR).

Nevertheless, if we really need a TLS redesign to address new goals and
requirements then let's just do that, name it TLS 2.0, gather all the
requirements and design it from ground up, not with arbitrary
un-coordinated actions during a maintenance release that has specific
charter goals (and record layer modification was not in them). Or if
that's not possible the interesting parties should proceed with a
separate contribution that provides length hiding and content hiding if
you consider that important.

regards,
Nikos