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

Florian Weimer <fweimer@redhat.com> Tue, 17 October 2017 12:53 UTC

Return-Path: <fweimer@redhat.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 C68F7132FB1 for <tls@ietfa.amsl.com>; Tue, 17 Oct 2017 05:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.022
X-Spam-Level:
X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 G_Tsp3cxC8zE for <tls@ietfa.amsl.com>; Tue, 17 Oct 2017 05:53:17 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DDA134184 for <tls@ietf.org>; Tue, 17 Oct 2017 05:53:17 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AFA4465DA3; Tue, 17 Oct 2017 12:53:16 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AFA4465DA3
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com
Received: from oldenburg.str.redhat.com (ovpn-117-7.ams2.redhat.com [10.36.117.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9DE3977677; Tue, 17 Oct 2017 12:53:15 +0000 (UTC)
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Hubert Kario <hkario@redhat.com>
Cc: 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>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <eaeae6e9-dd17-1482-ccae-2af6a14a8b18@redhat.com>
Date: Tue, 17 Oct 2017 14:53:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 17 Oct 2017 12:53:17 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/K3ZdmbNtqRlnCG8twwEYt9GXiHg>
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 12:53:19 -0000

On 10/13/2017 02:45 PM, Stephen Farrell wrote:
> So the problems with that are numerous but include:
> 
> - there can be >1 carol, (and maybe all the carols also need to
>    "approve" of one another), if we were crazy enough to try do
>    this we'd have at least:
>        - corporate outbound snooper
>        - data-centre snooper (if you buy those supposed use-cases)
>        - government snooper(s) in places where they don't care about
>          doing that openly
>    ...port 80 would suddenly be quicker than 443 again;-(

And any authorized eavesdropper is not allowed to be able to infer if 
they are the only ones listening in.

I don't understand why this complicated approach is needed.  Why can't 
the server provide an OOB interface to look up sessions keys, or maybe 
export them proactively?  The proposed draft needs a protocol like this 
anyway because SSWrapDH1 keys need to be distributed, and periodic key 
regeneration is needed because it is the only way to implement 
revocation of access privileges without revealing the existence of other 
authorized parties.

I don't buy the argument that there are too many session keys for 
proactive export.  Obviously, you already have sufficient capacity to 
send these keys (or an equivalent) over the wire once, so sending 
another copy or two shouldn't be a problem.

Thanks,
Florian