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

Melinda Shore <melinda.shore@nomountain.net> Tue, 13 March 2018 17:21 UTC

Return-Path: <melinda.shore@nomountain.net>
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 0EF2A1275F4 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 10:21:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.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 3FFgKd5fvSC6 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 10:21:08 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 82C88127599 for <tls@ietf.org>; Tue, 13 Mar 2018 10:21:08 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id h19so144042pfd.12 for <tls@ietf.org>; Tue, 13 Mar 2018 10:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=dsnGH86vKGqoL+rdAx1s6++sQFWKu6mx5vzptGO1FAE=; b=KEGUev3syJmzturOzyeC8g+7VVy02f8hb/oH/0iGj6iMheuMu18pW7OxqW/9gLIlSy xEiDsXjppiLN9hMlhq/ntPLfN5tVxLQfjPR0RkA7v7vX06l32zKa+Ilkd2du1ZioouTr esinlDm2/EL8rcbE07dZelWBUqAPAn8C6wgGst/jWK6Qv8wv9AxFM18XDhWdWI5/a6w9 xIZMlLCcrjnfsVUrmza19CnRmuqDlLhvZwdX97dAKja8EctlZHZaMVOxcb3hBrP/R+BA gg1SBVUY7bB/OHArwr6uWznvMs0FftkX6SgP6ejcbazUD7/g9WnzJw5OUE87LayI4vg5 +n9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dsnGH86vKGqoL+rdAx1s6++sQFWKu6mx5vzptGO1FAE=; b=T/6QlfHLYGygQ4yRX645QhCTY1GmGasWRdmaoXLPdqq4aWuLK49shLDAOr5a0/x8SR hk6eGTdnYDCZbxeEC3iD2aNhZZflEATz/77/d4XLtiF5WKmr6iGGvwLRk4VamZTFO08Q Xkbpevk/tUzh+34oKZUaC1EEQc+TD+u4ICrIQ0YJsmmcu3wErWXsMCySn1hIRQoKItuW 5DYUUG6rH47RRituBn+Mpn6qE2msZByCJgmu5T8vkJXJpzoe+8qVQeXvphJPASIbcWGb oQPpt7CQbqasKwPQ/HRSJJHIE1EmSugC3YeUCe+8uv4WQSA8b3e4hP/NcKYpVMhwp/l+ taDA==
X-Gm-Message-State: AElRT7Fi93KrQnN3axJRv/r7NbxKFyUGrpMsbf1w2f7DKq35QH1LG/TO Xk5+/tMXSCue4eXF9xjwANVpVCY=
X-Google-Smtp-Source: AG47ELtIykFRaxwyZVuNMfaTMmqZYc5E8stLBaUIYJRq58NAwO09xmijl6MGa/auzFSRf4cCvafDsw==
X-Received: by 10.101.68.141 with SMTP id l13mr1131863pgq.216.1520961667786; Tue, 13 Mar 2018 10:21:07 -0700 (PDT)
Received: from aspen.local (209-112-197-161-radius.dynamic.acsalaska.net. [209.112.197.161]) by smtp.gmail.com with ESMTPSA id q6sm1236518pga.37.2018.03.13.10.21.06 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 10:21:07 -0700 (PDT)
To: tls@ietf.org
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>
From: Melinda Shore <melinda.shore@nomountain.net>
Message-ID: <757b5c43-e346-47e7-9fc1-c64b901202e2@nomountain.net>
Date: Tue, 13 Mar 2018 09:21:04 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <57A8E13A-AC4D-49F3-A356-4C94AC6ABFCA@rfc1035.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZZpHP8OT4fA9CQLjvKfdZEJIxDRlPv0WI"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VFk7e65FZ_TEIlvCnluvjVA7eas>
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 17:21:11 -0000

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.

> 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.

Melinda


-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F