Re: [TLS] TLS@IETF101 Agenda Posted

Ted Lemon <mellon@fugue.com> Wed, 14 March 2018 12:32 UTC

Return-Path: <mellon@fugue.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 3FEF41270FC for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 05:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.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 3AicQ9ztA8Hg for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 05:32:13 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 BD89C1242EA for <tls@ietf.org>; Wed, 14 Mar 2018 05:32:13 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id g184so3180727qkd.10 for <tls@ietf.org>; Wed, 14 Mar 2018 05:32:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JgETBGBkHFOpFeKZKiq8e3aHwbQuMIuVJV0f438E5ik=; b=ittdvmuP3SwxsK1Ajj7gmgLFTRiI3JwEy8gtXumn0b+99PHVrSo1wdFsr2+lLLEFu5 g4ulfcR+lwjxpdj3C1muCKO4hP8DLka60i3Bl6aigfrGZHdvV73DX6kK0rzuIfm1ezM6 AFTakXC/Ox/cX2XklFH3ndaduZ2Z1xoWSrGpKL27um6a0lX9+XLVYwAnNYpEssqjh/j/ Bclw3ddB8ZnYtz6mKWL2s8yQEIFhvnTFpp+1W8haXLr4XPIBGy300zYLb2O6Ag0tESAU qq9KhOqaWKlW6b7K2Djl9HnIB/n+ozB1xamaE5W7zDNYoy8iYgLu4c/rxoBJjun/opKG tbnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JgETBGBkHFOpFeKZKiq8e3aHwbQuMIuVJV0f438E5ik=; b=EAyFGXXirtDSF/SiHlG+l6mHOSO9BzNnpok1eMTw+Q6TDeRWfzXJl0c4BybJGvuHP2 916H6eOkP2wP7uU6CFQwVLVYdqxxYhN7DNgkoI5OOs7IHIghMAFDd6ozbj3EF8571VtB /hygaSzhr82abIICz16JUNSuyUA7H4p4dk8TsTWJnNdx9Uw5m0rtEy8ih5HbaPWdQW9e AZbiKdBpGPOS0D7s2rT82uJZZXnK6O9dL1nilosD0DZm14uZL6pqr6QRh4yaGj/Ovju6 +ZwrcNkxU7YcUaAZAAHi6s8cnwJVY+Jwc6637DuzjK9/pkWQkMYhiy/HU8UgFYHf5sA4 6hvA==
X-Gm-Message-State: AElRT7GzfoIsa4RZ+rZ+OvN1+/hzEJ0mkoALkKL/6f6IL/hzj+sEALho uhX2w144eJe6Hz+CpRvvtfPehw==
X-Google-Smtp-Source: AG47ELuJevSz31F+Ddrw64s0bmmDm1DcSY0f8ZJEzQO8GoaxtmIcj6P+0B6xuT+tZTKj7hIKaQ2aqg==
X-Received: by 10.55.27.27 with SMTP id b27mr6673588qkb.168.1521030732787; Wed, 14 Mar 2018 05:32:12 -0700 (PDT)
Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j10sm1807256qtb.50.2018.03.14.05.32.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 05:32:11 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <43FCEF8E-E066-4FEA-AADF-7305D940B4E8@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_48B9E162-B6BE-4EB8-B317-092E8A446A8B"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 14 Mar 2018 08:32:10 -0400
In-Reply-To: <773EFF8D-4227-454D-AA1A-EA934C7042A4@vigilsec.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, IETF TLS <tls@ietf.org>
To: Russ Housley <housley@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> <773EFF8D-4227-454D-AA1A-EA934C7042A4@vigilsec.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MxgsE3PcpTrWMFTJhjgNQMP-eF8>
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 12:32:15 -0000

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?