Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 13 March 2018 18:45 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 CDB0E126C2F for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 11:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 lkhu9pVuA1_p for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 11:45:04 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 5E7171200F1 for <tls@ietf.org>; Tue, 13 Mar 2018 11:45:04 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id u5-v6so1472407itc.1 for <tls@ietf.org>; Tue, 13 Mar 2018 11:45:04 -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:content-transfer-encoding; bh=l7QeINPolcLz0J2gaPV3HDmJXV7fhEjnU38vprFeusg=; b=VLl9JjGqAonKHTed2fIpeCv32xdaSiBRJT3wzzw7hXwmFwlGoCjAaTWr3MvmNnw44+ e62IqJalxYFeOj/apRnk8CL11PjkqfYmXpx27FrwIfAya1dImTtfo+l6Y0aX+0KfLlFO V1TmX2hbc7DeM7Ti11fNxeVqDbaI9T1qVmSjYtvzp9WUmacppeH6QCFT90n0Hb7pKab5 sHsFb8B9/my4Z/AibsgX6zypLEOZXxIKW/qvlqhmgqtovofIkCoR7GoDmHFccJXMtHg0 cJzmP4KnJmLlsGjeXEC2rM9zHViWL56pFmnO2Sl+65QFHJbeEsH7LYABhxSQo9nglaIz 9E5Q==
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:content-transfer-encoding; bh=l7QeINPolcLz0J2gaPV3HDmJXV7fhEjnU38vprFeusg=; b=YydPYL+ZY8YII/WvC8Yrui0i6pD5IZdgsmRdsuciIdPHViqfMuiNivCliX2rl7TWIu ebtMcXm19IdmLwifzvT5a3czgebtpaOL+SqpUTg505qc9bEAl6p7WKduWJ3LtHHTY3GH +6TwXBKnZXEpdg0sKPEUmytcq5+hleZ1advnrAXzv1f5fok6rZdgUsCP87pODUkbYW+R WoiBr25tup0s+JhEaHA3hkkt4FO9fAdg5VegeWH/r78pyeWPJEoXcfK3k2IoE8EPu9+V jR4LXmRpsFLS7XPa/Hq2waI/jKVmviSxVpWC1vcLk9bxpGHzuuc0tluFUqngV/m0wrfQ wUlQ==
X-Gm-Message-State: AElRT7FYWpgaxszPiwpobRPDjpJXGMROLSBxqB5jV69/HJqXaaz1uQPl ew9O04dadsWxsOHtsVC6LcIVE+XQxSPL80WMYJw=
X-Google-Smtp-Source: AG47ELtk+MWpvpCXoSQh96iiZe5+JddC/e2ppzVjsLM39J1bvxAi92ubidpg1OvMGufi09seRkxl8HaQzsHE7JdvD/Y=
X-Received: by 10.36.211.86 with SMTP id n83mr821968itg.23.1520966703590; Tue, 13 Mar 2018 11:45:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.156.137 with HTTP; Tue, 13 Mar 2018 11:44:23 -0700 (PDT)
In-Reply-To: <757b5c43-e346-47e7-9fc1-c64b901202e2@nomountain.net>
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> <57A8E13A-AC4D-49F3-A356-4C94AC6ABFCA@rfc1035.com> <757b5c43-e346-47e7-9fc1-c64b901202e2@nomountain.net>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 13 Mar 2018 14:44:23 -0400
Message-ID: <CAHbuEH6jr0OSAt5KAeMytiA6crG15igvuCiW5fGcw26k3LogqA@mail.gmail.com>
To: Melinda Shore <melinda.shore@nomountain.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tCCfY38kaadItU_mZ_t83_mMFXY>
Subject: Re: [TLS] 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: Tue, 13 Mar 2018 18:45:07 -0000

On Tue, Mar 13, 2018 at 1:21 PM, Melinda Shore
<melinda.shore@nomountain.net>; wrote:
> On 3/13/18 6:48 AM, Jim Reid wrote:
>> Stephen, the opposite PoV is equally valid. There was no consensus in
>> Prague NOT to work on the topic. The mood of the room was evenly
>> divided.
>
> To clarify, this isn't voting.  If there's no agreement in
> either direction there's no agreement (and I hope the default
> in the IETF is not that in the absence of agreement, work
> goes forward).  The problem is how to come to agreement, and
> what that typically involves is refining the proposal to
> address objections.

And then there are other options too, like another WG.  Even from
Stephen's list of who is in agreement with him, I've received a few
messages saying their text wasn't what he thinks it was.  More
discussion here would be good to figure out a way forward.  The chairs
have not agreed to allow the work to go forward, but just the
discussions to determine next steps.

>
>> IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to
>> drop that draft and come back with a new one which would hopefully be
>> more likely to get WG consensus. That draft has now arrived. It’s
>> unreasonable to deny the new I-D a fair hearing and even worse to
>> reject it out of hand.
>
> It's surprising that it got agenda time without mailing list
> discussion.  Aside from the changes to the key
> exchange there are some clear usability problems.  While
> usability usually lies outside the purview of the IETF's
> technical work, in this case the work is premised on the
> ability of the user to consent (or not) to sharing keying
> material with a third party, which in turn suggests that
> they're presented with the question at the time the
> session is initiated, so that the extension isn't sent in
> the ClientHello.  Sounds like a click-through problem,
> tbh, where the user has little practical control over whether
> or not their data are shared with a third party.

This should have had discussion time in Singapore, as the chairs
mentioned.  I'm mostly responding though because their use cases are
entirely server-to-server from what I understand.  The client
connection to the enterprise can terminate at the network edge, then
anything within the enterprise is from another encrypted session
(which could be TLS 1.2 or another protocol, or this proposal, or
something else including methods that eliminate the architectural
design for monitoring on the wire within the datacenter).  If there
were a way to limit this extension to server-to-server, that would
eliminate the click through problem you mention and the server admin
would be aware on either end of this usage.  I don't know if there is
a way to do this without using another protocol, but making the use
case clear may help with ideas.

Best,
Kathleen

>
> Melinda
>
>
> --
> Software longa, hardware brevis
>
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>                  34C0 DFB8 9172 9A76 DB8F
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen