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

Ted Lemon <mellon@fugue.com> Tue, 11 July 2017 20:03 UTC

Return-Path: <mellon@fugue.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 D90671317BC for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 13:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 6QNf6of5Sgb8 for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 13:03:57 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 09CD5126DEE for <tls@ietf.org>; Tue, 11 Jul 2017 13:03:56 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id 32so2536223qtv.1 for <tls@ietf.org>; Tue, 11 Jul 2017 13:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j7uwddLdn1QxlFBh7P4IuMKCDW/m+HSNBjNYrJZbhl4=; b=YWOj6cVl4aHtbvRzKjic76JV0RHCr+wHTmf2/89p5KC1wFKD6/jaWjWbqwVFQLIvJY rX2xMo7OeZ7ph9dPa3GzW2bCw9WMUu5weAgvHRdqypE2WDcso/KPe8ZTdxhH8NH2lbaS +LaEPHFE5lExujwTqg/CFUeY6DLdrqTdg2zPqjIVW/5d6kEX1te5eg+s9HXlPS5URSbE hARC/hGbOSHg2d62X96q1f1ZLyIkaU+rB5z5d+YdFRb33m2xS6NGleMUCrFf0DjFzcVW yohqixP2ubLGnEzrA+S90GX1FQyIRLMEDRLmAIVWjUI47/DQ0/DplM+61w963+WnN/ob aVPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j7uwddLdn1QxlFBh7P4IuMKCDW/m+HSNBjNYrJZbhl4=; b=qtSxcA/Czva+Kyk25FzHVs7Hkl/qQII/UKwj7Y0w8ui1EXZkx2JbjA2dUWk17j0ha7 qx6u2b1nZQF0zKz81ReIFvBilJRCJioPMODgNRT0PBOdtLkfqVmKr1e7sULmtRx9Gnfh TNPEjmFc1b//9UtskYIgGBRPjBaftzjkUGrxyyRq4px+a8bx9VeWrUZbl8sArwQFL/Eo bndKK9ZeZRLeab0Tb2u9b3JmZrZTsK72NgxC26xWES4FxmUPxOllXX/BwkzwpSB6l33l jOCEsyzmGgHxYJa38tItN6MGV5gqbuSSyLiybyAAHQGBeeUfhoFhktsTRsjWKoTqcrIM FvGg==
X-Gm-Message-State: AIVw112Ipf9Yd5gJBvZtze0Zka3rKyzIp0KroEkqtTXiv2k9TBzf03at 5alEEa+sDZiOiDFGnljtXA==
X-Received: by 10.200.49.18 with SMTP id g18mr2341190qtb.118.1499803435946; Tue, 11 Jul 2017 13:03:55 -0700 (PDT)
Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q185sm178022qkb.45.2017.07.11.13.03.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 13:03:55 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E178CAD-D65A-4FAC-A9ED-B624FA8D5601"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 11 Jul 2017 16:03:53 -0400
In-Reply-To: <bcda4dab-3590-9162-5f5c-c453f7a610ac@cs.tcd.ie>
Cc: Christian Huitema <huitema@huitema.net>, tls@ietf.org
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_V1wv_0AJonngBjR-c518yRn1tU>
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:03:59 -0000

On Jul 11, 2017, at 3:59 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>; wrote:
> I can't see that happening. Once the first example.com <http://example.com/> is called
> out for using this, others will make their list longer or take
> other approaches, e.g. use one exfiltrated private value as a
> seed for others via some proprietary mechanism.

Ah, you mean the first time the attack happens in the wild.   Sure, I can see that, but that gains the attacker no real advantage over just exfiltrating all the keys.   Once you make the number of keys large enough to be hard to detect, you have a really big key management problem.   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.

> Actually, that calls out another reason to not standardise or
> further develop this - any such standard is either undetectable
> or leads to deployments deviating from the standard to become less
> detectable - both undesirable outcomes. That latter case also
> destroys the "but we should scrutinise it" argument IMO as the
> "it" will change to be undetectable and not the "it" that was
> ostensibly scrutinised.

I'm not arguing in favor of standardizing this.   I think it's an attack, and there is a countermeasure which is worth documenting, and possibly worth deploying.   If the working group does a CFA on the draft, I will argue against adoption.   I like Christian's approach—document this in an appendix, _as an attack_.