Re: [TLS] Encryption of TLS 1.3 content type

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 28 July 2014 08:55 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 A85FE1A0311 for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 01:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.603
X-Spam-Level:
X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 q7GN3Eb3HkGw for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 01:55:56 -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 2E9C01A02FF for <tls@ietf.org>; Mon, 28 Jul 2014 01:55:56 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6S8trGZ021936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jul 2014 04:55:53 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6S8tpEj008686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 04:55:52 -0400
Message-ID: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Date: Mon, 28 Jul 2014 10:55:53 +0200
In-Reply-To: <CAAF6GDfK7awipoMT_PPyKnTe-fF1=KY1Be8kUMSYrXN0Wzb=tg@mail.gmail.com>
References: <DD255E31-FA87-40CE-AF13-0F43A7DD54CF@cisco.com> <CACsn0cnt-ry182AjOyTTZGteifs7VyRPYHaj-xDCBOf0D53w9A@mail.gmail.com> <CAAF6GDfK7awipoMT_PPyKnTe-fF1=KY1Be8kUMSYrXN0Wzb=tg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MPovzgo1cTeNPo_hS0eRW2GRJzI
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 08:55:57 -0000

On Sat, 2014-07-26 at 10:59 -0700, Colm MacCárthaigh wrote:
> On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd <watsonbladd@gmail.com>
wrote:
> > This is a change with no rationale: the content type leaks extremely
> > limited information. It complicates implementations that wish to
keep
> > a high degree of codepath similarity between TLS 1.2 and TLS 1.3.
> Leaking alert messages has been a recurring theme common to several
> attacks; hindering a MITM's ability to discern alert messages seems
> like a rational rationale.

Are there any pointers to these attacks? Will these attacks be countered
with such a change? I believe not as alert messages consist of only two
bytes and will be distinct from any other higher protocol messages
transferred by the TLS record protocol. Unless TLS 1.3 intended to
include a length hiding mechanism I see this change as unnecessary and I
agree with Watson on that.

If we cannot avoid changes to TLS 1.3 charter, I believe that any new
proposal comes with a concrete case for it and associated costs of
implementing vs not-implementing. The initial agreement was for a small
revision to TLS (even though I didn't agree on that), and that is now
used as a vehicle to push unrelated to the charter major changes with no
planning whatsoever. I'm afraid in the end the result will be an
ISO-type of protocol.

regards,
Nikos