Re: [TLS] chairs - please shutdown wiretapping discussion...

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 11 July 2017 20:31 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 287BE1317DA for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 13:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, 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 Snc7M70T897O for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 13:31:27 -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 123A41317D5 for <tls@ietf.org>; Tue, 11 Jul 2017 13:31:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9560CBED6; Tue, 11 Jul 2017 21:31:25 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 TI2udIc3NAjl; Tue, 11 Jul 2017 21:31:24 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F787BECA; Tue, 11 Jul 2017 21:31:24 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499805084; bh=V4Mf4H4xxNbSjC/R8dfkga468KxoeE10f82WOYvh5Ro=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KKTuwoeCk2fyrBlNs0RqZnSOUYGQ1MszT7i+RgoIkHEga/bvdbrPl2AswPPyhaRSc Y8yyEVNmxO1z1uItqbICyAsCNii4574Qiouqfxwj0EcUIX2kzJce0St0N1rUZopEu2 TZcQCXQ6lJyqCREZNlLI1XEALLz7PRCEqCQQtNWQ=
To: Ted Lemon <mellon@fugue.com>
Cc: Christian Huitema <huitema@huitema.net>, tls@ietf.org
References: <E9640B43-B3AD-48D7-910D-F284030B5466@nist.gov> <CY4PR14MB13688370E0544C9B84BB52A3D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <CY4PR14MB1368BA01881DD9495FE86DF0D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <d806a69c-af30-c963-a361-91075332a61b@cs.tcd.ie> <F87D7646-DC53-4EF8-A2D8-D0939A0FB351@vigilsec.com> <b9001044-83d7-805c-2a49-c2780401bbf8@cs.tcd.ie> <C4125902-CA3A-4EA8-989B-8B1CE41598FB@fugue.com> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <fa6e64a2-b1c8-9c55-799b-b687b830a246@huitema.net> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <CD0E0745-EA72-41D9-87F6-B40369ED6A70@fugue.com> <bcda4dab-3590-9162-5f5c-c453f7a610ac@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d9870cd0-476c-b255-16bd-594e24cd91f0@cs.tcd.ie>
Date: Tue, 11 Jul 2017 21:31:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JDLXUQKVJFqU96JQkoEXRla2tVJmWEjVW"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qubMwTf3TtrmtTkw4GzFLAGKLUA>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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, 11 Jul 2017 20:31:29 -0000


On 11/07/17 21:03, Ted Lemon wrote:
> Ah, you mean the first time the attack happens in the wild.  

Well, the first time it's detected in the wild.

> Sure, I
> can see that, but that gains the attacker no real advantage over just
> exfiltrating all the keys.   

I agree. I think one can actually generalise here and argue
that there's no value in new standards for bad crypto, only
in standards for current BCP crypto. (On the basis that if
it's crap crypto there's too much damage potential in the
homogeneous environment created by a successful standard.)

> Once you make the number of keys large
> enough to be hard to detect, you have a really big key management
> problem.   

Not necessarily. I'd bet folks would invent proprietary
ways of avoiding detection, that deviate from the "standard"
and that perhaps make crypto worse all around. Say by deriving
secrets from some function f(exfiltrated-secret, time, count)
for a small counter or some such and having the decryptor of
the wiretapped packets hunt a bit for the right key.

> Might as well just make it a logging problem.   So we've
> forced them to do the thing that makes pervasive monitoring hard and
> point monitoring easy.   I call that a win.
> 
> Note that if we took a distributed approach to discovering key reuse,
> it would be almost impossible for any large site to conceal.

I would bet there are ways to hide from that.

Cheers,
S.

PS: There are also genuine performance reasons why the same
DH public might be re-used in some cases, so there would be
false positives in a survey to consider as well.