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
- [TLS] Encryption of TLS 1.3 content type Joseph Salowey (jsalowey)
- Re: [TLS] Encryption of TLS 1.3 content type Yoav Nir
- Re: [TLS] Encryption of TLS 1.3 content type Fabrice Gautier
- Re: [TLS] Encryption of TLS 1.3 content type Eric Rescorla
- Re: [TLS] Encryption of TLS 1.3 content type Watson Ladd
- Re: [TLS] Encryption of TLS 1.3 content type Colm MacCárthaigh
- Re: [TLS] Encryption of TLS 1.3 content type Peter Gutmann
- Re: [TLS] Encryption of TLS 1.3 content type Yoav Nir
- Re: [TLS] Encryption of TLS 1.3 content type Nikos Mavrogiannopoulos
- Re: [TLS] Encryption of TLS 1.3 content type Yoav Nir
- Re: [TLS] Encryption of TLS 1.3 content type Daniel Kahn Gillmor
- Re: [TLS] Encryption of TLS 1.3 content type Martin Rex
- Re: [TLS] Encryption of TLS 1.3 content type Colm MacCárthaigh
- Re: [TLS] Encryption of TLS 1.3 content type Nikos Mavrogiannopoulos
- Re: [TLS] Encryption of TLS 1.3 content type Daniel Kahn Gillmor
- Re: [TLS] Encryption of TLS 1.3 content type Nikos Mavrogiannopoulos
- Re: [TLS] Encryption of TLS 1.3 content type Viktor Dukhovni
- Re: [TLS] Encryption of TLS 1.3 content type Brian Sniffen
- Re: [TLS] Encryption of TLS 1.3 content type Stephen Farrell
- Re: [TLS] Encryption of TLS 1.3 content type Michael StJohns
- Re: [TLS] Encryption of TLS 1.3 content type Yoav Nir
- Re: [TLS] Encryption of TLS 1.3 content type Colm MacCárthaigh
- Re: [TLS] Encryption of TLS 1.3 content type Juho Vähä-Herttua
- Re: [TLS] Encryption of TLS 1.3 content type Eric Rescorla
- Re: [TLS] Encryption of TLS 1.3 content type Andy Lutomirski
- Re: [TLS] Encryption of TLS 1.3 content type Peter Gutmann
- Re: [TLS] Encryption of TLS 1.3 content type Alfredo Pironti
- Re: [TLS] Encryption of TLS 1.3 content type Martin Rex
- Re: [TLS] Encryption of TLS 1.3 content type Alfredo Pironti