Re: [TLS] TLS@IETF101 Agenda Posted

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 14 March 2018 14:22 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 4435D1273E2 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 07:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HFbZVxYrw3P6 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 07:22:34 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031DD1273B1 for <tls@ietf.org>; Wed, 14 Mar 2018 07:22:34 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id w3-v6so4800328itc.4 for <tls@ietf.org>; Wed, 14 Mar 2018 07:22:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ITyNUJYihpLjH7EcOIqKL6fxL1WRoE6Zy8i8fn0etRQ=; b=OCsIOlC7HY4v1Rk1XJlINulZwcxN3q+MMQHHr0ElDSyCXKUMoIQWqwS+3osRc0NtgU qAFwk8MALkaHq0g21LzsCQTOUaf/zryl5NPPp9eS5Krk8FNfEIL3iA2+GWZP8EGXxtYc mq8G6Q3Wr7jRTyY+fL8xF5+S6F4w7zWsglitdhuTV5K1x2m/8ww8mO598PwYzoa1H4aD tiqjnZeydz4Iq9N0WXmuIZ0EA/GKMZyh7M9Od4Siu3KsumvYVbDZWjmbzdElRTwS9EUh obIshs+g/21RZ2aBny6LlHQtxKXGQ69dTxOusZDTN7mr7vsKUaGeJ3Tb/eD7K/fC4PT9 x28g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ITyNUJYihpLjH7EcOIqKL6fxL1WRoE6Zy8i8fn0etRQ=; b=D38MPTBcGhjGbxorPmOVsStlIB1hPCvhZTB5pr+ILpO8WJTYXnyhEwmFD6D551LdHl fD5bb/C7iS5oDb/Lo2LjhtJe7YN8u9u5SDLqSESmOAnLPR3cHtc01R7EqrvO1vpZPEaj iDBiS3Fe1BqbIEdbyF5H9byiiWWcVxw3ecWD4Kgw+c3IfFSYEdUb26uSF6LJrE7X55ba 5RKC930Yx9HfHP/o8cRPdkXADqsZ5MzDOUAeG3zqOuwPx8sw2x5RGR7H2wiE5iFQixJs HhdojzUwWvIN+cM8C7uUNCxhO61KBTp5PIU3k9LXuOhVfr9mIftuQTqP71UXCy+oErMF n+qQ==
X-Gm-Message-State: AElRT7G07WKnUJvBIUM/niSkFY/+KSwjRDBT9A0vCg/4WIPHCGSS5tKi hbEXUFodbnX+++OY5OOofbMAUQygy8u9PvUB4mQ=
X-Google-Smtp-Source: AG47ELvhHAc9kQy1Fkiz/0c+V+CfrV5Ph3GzkvWRsWRQJydmoIqhYk1tOlVWAZiaZYB+KMvdy3LgVIBLxRvLMK7lJRA=
X-Received: by 2002:a24:d356:: with SMTP id n83-v6mr2093243itg.23.1521037352813; Wed, 14 Mar 2018 07:22:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.156.137 with HTTP; Wed, 14 Mar 2018 07:21:52 -0700 (PDT)
In-Reply-To: <43FCEF8E-E066-4FEA-AADF-7305D940B4E8@fugue.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> <773EFF8D-4227-454D-AA1A-EA934C7042A4@vigilsec.com> <43FCEF8E-E066-4FEA-AADF-7305D940B4E8@fugue.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 14 Mar 2018 10:21:52 -0400
Message-ID: <CAHbuEH74J_wxTSocN1PeDA9NW_NwwxDopVCw4L_Nzz2F=MeBbA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Russ Housley <housley@vigilsec.com>, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hRXDiAcOqqC1hawQeaOzg1M1aKE>
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 14:22:35 -0000

On Wed, Mar 14, 2018 at 8:32 AM, Ted Lemon <mellon@fugue.com> wrote:
> On Mar 13, 2018, at 11:49 PM, Russ Housley <housley@vigilsec.com> wrote:
>
> 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.
>
>
> I had thought that we had agreement in Prague that this proposal did not
> require special browsers to be widely available in the wild.   If it does,
> that seems like a mildly stronger argument against it, since if the
> requirement for this behavior successfully infects browsers in the wild, the
> damage done will be to connections in addition to the ones that you are
> trying to wiretap.
>
> Is there still confusion on the question of whether click-through warnings
> can ever be part of an effective user interface design?
>

I think you'd get further (not sure how far), if this were limited to
within the datacenter and without a need for browser implementations.
If it were specific to browsers for use within an enterprise, that
would be one option, but another would be to see if this could be
limited to server-to-server only connections with no need for a
browser.  If you're terminating at a load balancer and then starting a
new session with the extension, this could be done for internal and
external users.



-- 

Best regards,
Kathleen