Re: [TLS] Industry Concerns about TLS 1.3

mrex@sap.com (Martin Rex) Wed, 28 September 2016 13:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4220F12B280 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 06:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3bsVvkicuN30 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 06:34:45 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7D312B138 for <tls@ietf.org>; Wed, 28 Sep 2016 06:34:43 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3skdwd6Bmrz25Pw; Wed, 28 Sep 2016 15:34:41 +0200 (CEST)
X-purgate-ID: 152705::1475069681-0000521C-F2430DA4/0/0
X-purgate-size: 1804
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3skdwd5Z5VzksWS; Wed, 28 Sep 2016 15:34:41 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B42B71A558; Wed, 28 Sep 2016 15:34:41 +0200 (CEST)
In-Reply-To: <20160928132935.C46711A558@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Wed, 28 Sep 2016 15:34:41 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160928133441.B42B71A558@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wHjdajZojfSe8PIKZ_pC_F4G80k>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 28 Sep 2016 13:34:47 -0000

Martin Rex wrote:
> Stephen Farrell wrote:
> > 
> > On 28/09/16 01:17, Seth David Schoen wrote:
> > > People with audit authority can then know all of the secrets,
> > 
> > How well does that whole audit thing work in the financial services
> > industry?  (Sorry, couldn't resist:-)
> 
> I am actually having serious doubts that it works at all.
> 
> Consider a scenario that uses TLSv1.2 with static-RSA key exchange,
> plain old session caching and Microsoft style renego-client-cert-auth
> on a subset of the urlspace.
> 
> (1) first TLS session, full handshake, request to public area.
> 
> (2) TLS session resume, request to non-public area -> renego
> 
> (3) TLS session resume for renego'ed session to non-public area.
> 
> 
> To obtain the cleartext of session (3), you'll need the master secret
> of the renego'ed session from (2), for which you'll first have to locate
> and decrypt (2), for which you need the master secret from (1), so you'll
> have to locate (1), and only at (1) you can start opening the encryption
> with the longterm private RSA key of the server.
> 
> It is impossible to open (3) directly, and the ClientKeyExchange
> handshake message (and client&server randoms) that created the master secret
> of session (3) is encrypted during renegotiation, so one can not
> directly recover that with the longterm private RSA key of the server,
> but has to open (2) first.

And it might even be more difficult than that.

Because the Server Hello (with the server-issued new session_id)
is encrypted during renegotiation, one can not see which renegotiation
created the session that is resumed in (3), and may have to decrypt
several renegotiation handshakes in order to find the correct one
which created the session_id (3).

-Martin