Re: [TLS] TLS@IETF101 Agenda Posted

Russ Housley <housley@vigilsec.com> Wed, 14 March 2018 03:49 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 EF4B3126BF3 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 20:49:26 -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 pNE_L-Z4G2VZ for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 20:49:25 -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 96326124E15 for <tls@ietf.org>; Tue, 13 Mar 2018 20:49:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7DD583005AB for <tls@ietf.org>; Tue, 13 Mar 2018 23:49:23 -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 a3xl375pxlAC for <tls@ietf.org>; Tue, 13 Mar 2018 23:49:22 -0400 (EDT)
Received: from [172.20.6.66] (unknown [5.148.123.140]) by mail.smeinc.net (Postfix) with ESMTPSA id 4D970300558; Tue, 13 Mar 2018 23:49:22 -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: <CAHbuEH4Sby-6Mi+5cWg7tvYSsL4Z6ALgUjpWNzbe-Ou2o0XmsA@mail.gmail.com>
Date: Tue, 13 Mar 2018 23:49:21 -0400
Cc: IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <773EFF8D-4227-454D-AA1A-EA934C7042A4@vigilsec.com>
References: <6140B7A6-A1C7-44BC-9C65-9BE0D5E1B580@sn3rd.com> <986797a7-81b0-7874-5f39-afe83c86635b@cs.tcd.ie> <CAOgPGoBYc7O+qmjM-ptkRkE6mRsOYgc5O7Wu9pm3drFp3TVa6Q@mail.gmail.com> <d7dfdc1a-2c96-fd88-df1b-3167fe0f804b@cs.tcd.ie> <CAHbuEH7E8MhFcMt2GSngSrGxN=6bU6LD49foPC-mdoUZboH_0Q@mail.gmail.com> <1a024320-c674-6f75-ccc4-d27b75e3d017@nomountain.net> <2ed0gc.p5dcxd.31eoyz-qmf@mercury.scss.tcd.ie> <d7ec110f-2a0b-cf97-94a3-eeb5594d8c24@cs.tcd.ie> <CAAF6GDcaG7nousyQ6wotEg4dW8PFuXi=riH2702eZZn2fwfLQw@mail.gmail.com> <CAPsNn2XCNtqZaQM6Bg8uoMZRJE+qQakEwvw8Cn9fBm-5H+Xn_A@mail.gmail.com> <3F8142DE-EADB-4AB9-A204-7D87ACDCD3E3@akamai.com> <CAPsNn2VE_7+rWT0fp9rrVnZrgcY7ORLWTee+kf_Av1dqm4CiDQ@mail.gmail.com> <CB55AABB-8937-4F6B-B5AC-B6F262F08A4F@akamai.com> <CAPsNn2U_xG28Tumo3oRkQ+6=BHzgv-6YtgNSpwvhdFFRWc7EQQ@mail.gmail.com> <2DC45296-244E-4C72-8B3C-DE47EADAC2DE@fugue.com> <BN7PR14MB23696A2767FF9C1A410110AFD7D20@BN7PR14MB2369.namprd14.prod.outlook.com> <090F06AF-371D-4B11-91AA-BD80C1ADB4E9@fugue.com> <C1970611-C781-41A8-87CA-D00629AC41E7@vigilsec.com> <35A28548-B200-447A-A3EC-365AAD491858@fugue.com> <7AD6659C-C85E-4AD1-A85A-3789471258FA@vigilsec.com> <CAHbuEH4Sby-6Mi+5cWg7tvYSsL4Z6ALgUjpWNzbe-Ou2o0XmsA@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/py6S-7__oqL9c0GbFETtiwzqwLE>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
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 03:49:27 -0000

>>>> Second, using TLS1.2 does not technically address the issue.  If the client
>>>> were to exclusively offer DHE-based ciphersuites, then the visibility
>>>> techniques that have been used in the past are thwarted.
>>> 
>>> The client in this case is under the control of the operator, so this is a
>>> non-issue.
>> 
>> In some cases, the client in the load balancer is under the control of the
>> enterprise.  In other cases, the client is in the customer browser, and
>> opt-in is very significant.
> 
> When you say customer browser, do you mean the users on the enterprise
> network behind the firewall, all within the control of the enterprise
> that owns the data?  I think this is what is meant since the Internet
> sessions from customers could be terminated at a load balancer on the
> enterprise edge and then this extension may be used between servers
> internal to the enterprise and from what you are saying, browsers as
> well.  Or is the plan for this to be opt-in from the customer external
> to the enterprise (I didn't think that was the case and it would be
> good to clarify).  This distinction would be helpful to know where
> traffic may be intercepted if there were another party that might be
> malicious.

I was trying to separate these two cases.  If the TLS session is terminated at a load balancer, then the client within the load balancer is (as Ted says) under control of the operator.  The operator can include any extensions that it wishes.  If the TLS session is not terminated at a load balancer, then the client needs to opt-in for decryption points in the enterprise data center to get the needed keying material.

Russ