Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 October 2017 16:29 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 647E313303A for <tls@ietfa.amsl.com>; Tue, 17 Oct 2017 09:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 0Uoo-dW47b3w for <tls@ietfa.amsl.com>; Tue, 17 Oct 2017 09:29:24 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A61126BF0 for <tls@ietf.org>; Tue, 17 Oct 2017 09:29:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A375DBE3E; Tue, 17 Oct 2017 17:29:22 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWEi8OeIwZGZ; Tue, 17 Oct 2017 17:29:22 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F50FBE38; Tue, 17 Oct 2017 17:29:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508257762; bh=5VLOAMIFiFwXAyCyf0528RG4zj0b/gcG6NWPxBjCMNo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jdJyXyqPs8t6XOnKmHEkNZpABw2+VxKZ0I9acskpxteTUCvdDVNWSeV/N9FN+FO7M hwNpmrovy2+fl0pAhGLQxXM8WrEpA/HYRV6NUiC6dWF+6vSautPBcd5ylKkRRKg408 mNWVGFxade1I5vQy3oFQ8dKZizoKBQrzv9H1Q6Fc=
To: Ion Larranaga Azcue <ilarra@s21sec.com>, Florian Weimer <fweimer@redhat.com>, Hubert Kario <hkario@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <d74976e1-6c0a-a833-178b-d0cfa9ef68cf@cs.tcd.ie> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <eaeae6e9-dd17-1482-ccae-2af6a14a8b18@redhat.com> <ba29233fe2aa48c78a6ee0e1f7f0584e@LXDOMEXC01.ssidom.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie>
Date: Tue, 17 Oct 2017 17:29:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <ba29233fe2aa48c78a6ee0e1f7f0584e@LXDOMEXC01.ssidom.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WmTtI3o7MwiewcOGvwM5wpH1Qs3tDouW9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PSYcOwdnDKEWdUXbQ2yLgW3wmQM>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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, 17 Oct 2017 16:29:26 -0000


On 17/10/17 16:46, Ion Larranaga Azcue wrote:
> The problem I see with a "server to third party" OOB look up or
> export of the keys is that the client will not be notified of this
> export taking place and so will lose the chance to reject
> surveillance...
IIUC, with the draft-rehired proposal, the client
can in any case not be told - the TLS protocol
extensions are mere politeness and the client does
not get to know what snooper(s) are involved, nor
can the client influence the snooping keys. Once,
any infrastructure for this was deployed, I think
it'd be used without telling clients for sure. (And
we would be fully complicit in helping that happen,
if the WG adopted this stuff, because we know that
such abuses would be inevitable.)

I think this WG was correct years ago when we
passed on the DNT proposal which had the same
"just politeness" aspect - the web is not really
such a friendly place that one can depend on the
kindness of strangers. Nor are many of the many
other applications using TLS.

S.