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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 12 October 2017 13:16 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 CA50F1344DE for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 06:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 3UH3QarCMHqM for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 06:16:11 -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 49D64134211 for <tls@ietf.org>; Thu, 12 Oct 2017 06:16:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C98B3BE38; Thu, 12 Oct 2017 14:16:08 +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 FSSXBdWU5ejY; Thu, 12 Oct 2017 14:16:08 +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 8927ABE2F; Thu, 12 Oct 2017 14:16:08 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507814168; bh=guBg46Xg3Sv1OdKTVxo1dAFTyMOf/3ps8zodQ2UC5qI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vuao7zjZWhCtVDsQ+1MbzhWozqIHlMMNPCxZlsdO7daKWjqowlGAvF8BtSlhomBl3 qJsQdd0quIIv2r8lVDe50mdUBEZySzidMLDvfuOIHI5woMuprPY/VXOhJCcDHgTbLG 6g1EmuzaPjYmVzQLrn+Hf6ss4bMPp12OiU/GOPu8=
To: Hubert Kario <hkario@redhat.com>, tls@ietf.org
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <CAOjisRywXfBfgWuZQPR++sHcK7M7vaKFMDea3XMA4tAUEs7HdQ@mail.gmail.com> <1507760676870.14256@s21sec.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d74976e1-6c0a-a833-178b-d0cfa9ef68cf@cs.tcd.ie>
Date: Thu, 12 Oct 2017 14:16:08 +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: <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="5AVM2QvW00rJ3LbuUMvd81aBcR3tUnXjC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/n_PdhlFymAO2SJnMCOZXxZ7pjLE>
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: Thu, 12 Oct 2017 13:16:15 -0000

(With the obvious caveat that I hate the whole
idea... :-)

On 12/10/17 13:57, Hubert Kario wrote:
>>
>> Anyway, I think key life length could be addressed in later drafts, but the
>> inability of the client to identify (and possibly reject) the tapping third
>> party is a "no go" for me...
> yes, a three-way DH with two certificates (one IPS one EE server) does seem 
> like a much better approach, especially if IPS certs need to have special 
> flags that make them useless for anything else and cannot be set by CAs in 
> public CA programs.
> 

But... even if one did add names/certs for the wiretapper
or IPS or whatever then there could be more than one of
those who'd like to be able to interfere with the TLS
session, and there's no way I can see that makes sense for
the client and server to negotiate which wiretappers they
allow/like.

This is all just squaring-the-circle, TLS is meant to be
a 2-party protocol (ignoring CAs) and I don't see any way
to make TLS a multi-party protocol that works.

S.