Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

Russ Housley <housley@vigilsec.com> Wed, 14 March 2018 19:25 UTC

Return-Path: <housley@vigilsec.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 D5DAD126C2F for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 12:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rEAwU8zW5cnu for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 12:25:41 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C722124BE8 for <tls@ietf.org>; Wed, 14 Mar 2018 12:25:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4AA893005AB for <tls@ietf.org>; Wed, 14 Mar 2018 15:25:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hFtkT_YNRuVr for <tls@ietf.org>; Wed, 14 Mar 2018 15:25:38 -0400 (EDT)
Received: from [172.20.6.66] (unknown [5.148.123.140]) by mail.smeinc.net (Postfix) with ESMTPSA id F1CF7300548; Wed, 14 Mar 2018 15:25:37 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CABkgnnUiQsCtQ+u_-yAg90FkLOM96PunqoeyeOP-9AvJhpdtPw@mail.gmail.com>
Date: Wed, 14 Mar 2018 15:25:39 -0400
Cc: IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A297A19C-923F-4632-9242-F7CF1D351065@vigilsec.com>
References: <CABkgnnUiQsCtQ+u_-yAg90FkLOM96PunqoeyeOP-9AvJhpdtPw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YTAjnSr7T2FHHMKTjFqPqrPs0lc>
Subject: Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <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, 14 Mar 2018 19:25:43 -0000

> On Mar 14, 2018, at 4:48 AM, Martin Thomson <martin.thomson@gmail.com>; wrote:
> 
> On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley <housley@vigilsec.com>; wrote:
>> Nick Sullivan summarized
>> four concerns with that approach.  See
>> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg
>> 
>> draft-rhrd-... addresses all four of these concerns.
> 
> This isn't quite right.  One of the goals Nick outlined was
> "Decryption service only gets session keys, not master secret".  The
> current design causes them to gain the handshake secrets, from which
> it is trivial to derive the master secret and other secrets [1].  This
> includes the resumption master secret and exporter secret.
> 
> So aside from enabling MitM, this also enables session resumption by
> the decryption service, something that the security considerations
> neglects to include in its list.  What, if anything, can be done with
> the exporter secret will need more thought.
> 
> [1] draft-rescorla-tls13-semistatic-dh-00 and its OPTLS-based
> insertion of another DH exchange would prevent the decryption service
> from working for anything other than the handshake and 0-RTT.

You are right.  It would be a significant improvement to narrow the portions of the key schedule that are shared.

To avoid the issue with resumption that you raise, is seems that these entries in the key schedule are needed:
	client_early_traffic_secret
	client_handshake_traffic_secret
	server_handshake_traffic_secret
	client_application_traffic_secret_0
	server_application_traffic_secret_0

Russ