Re: [TLS] Encryption of TLS 1.3 content type

mrex@sap.com (Martin Rex) Mon, 28 July 2014 14:41 UTC

Return-Path: <mrex@sap.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 BB3B61A0385 for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 07:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.252
X-Spam-Level:
X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 Onfc3w8CZjKY for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 07:41:12 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E7A941A0292 for <tls@ietf.org>; Mon, 28 Jul 2014 07:41:11 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s6SEdo9s021163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jul 2014 16:39:50 +0200 (MEST)
In-Reply-To: <CAAF6GDfK7awipoMT_PPyKnTe-fF1=KY1Be8kUMSYrXN0Wzb=tg@mail.gmail.com>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Date: Mon, 28 Jul 2014 16:39:50 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20140728143950.055491ADC9@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1xSVH0ZpdpmwkOme9X1VCqkc6t8
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
Reply-To: mrex@sap.com
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 14:41:13 -0000

I also object to the removal of the ContentInfo from the outer
TLS record protocol.  I'm not aware of the slightest rationale for
this severe backwards incompatibility, that will not just break
middle-boxes, but also applications that parse TLS records for the
purpose of non-blocking operation.


Colm MacCárthaigh wrote:
>
> 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.

Which attacks do you have in mind?  I'm actually not aware of any.

The Bleichenbacher PKCS#1 decryption oracle happened during the
cleartext phase (so this doesn't apply here), and while the
CBC guessing happened in the encrypted phase, the attacker was
in posession of the decryption key, could properly decrypt the
alert, and use it to distinguish decryption failure from mac failure
alerts.

So in both situations, content hiding would not have had the slightest
impact on these attacks.

-Martin