Re: [TLS] Breaking into TLS to protect customers

Yoav Nir <ynir.ietf@gmail.com> Mon, 19 March 2018 13:23 UTC

Return-Path: <ynir.ietf@gmail.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 0E3961242F5 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 06:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=gmail.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 HsDVY6OTV7kR for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 06:23:34 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 EBF1B12704A for <tls@ietf.org>; Mon, 19 Mar 2018 06:23:33 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id c24so6764232wrc.6 for <tls@ietf.org>; Mon, 19 Mar 2018 06:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Efo9PNiO+eNl55b/fnwHUmOFZ2IRXG9vam7VvKzlvsU=; b=DKQXYZG1F+m+8hp+FdVQlDiuBu+HsN+YmwYlHGrZatQpckEMZdITuylIVeWuaUxq4B w6/rG1Et61bV1AvhDv1upmcl6JH+UnRvlc6wUuIByhV4a3vO0WP4tCcNJRXuMc5nW/FQ /i/Bn3n2kMSOvk0HkdL8BeEQMK4YJrUiY4xW7NXfHb+l01Rx29qjM4nRaBc5DmKRNslu coUIPZZUAp09YoaEBUioNvds+KTW8JZbJA7XZPv3ffW4O4RDGXzlSr0NFcX4sW5CqS98 sCIsK9XM035uRj/akPlQCBJ3kqJS45nxPc6k9GdKBDBa+Ej6QY2EFnpdSO3reBsoR02/ nWLA==
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=Efo9PNiO+eNl55b/fnwHUmOFZ2IRXG9vam7VvKzlvsU=; b=HTE6vxOmW7cIGfL7Uo9WkdB48zsStd4PYpjwO+l9CzvSMdDZofEID1goIU+HdQRF9M 3gm9SX6OYhaVHNMv8NXRq6+ajN1zieENWFYDQOpMkzu/JLO8xjnfG2qDzC5kawyPegAc 4CoDu4f1FunBChviAOjWs4Q9nkp9udbZWXgAH8x1RVyDpjiKTWj1qGWbHgtFTlR0CKLK 4NeA+48PVWMPPgrEem9ZzVJhlyh89u/vZJeObI64Gh/yd/0b15SKMYCfq2RhOm8LupPQ nc964PPoANq/1F1fPjhSpXTksCeJNISQYEO+rgu8YpP6SZKD4cRta3EX6Cf+MdAdnt9v mLAw==
X-Gm-Message-State: AElRT7FdL1lI23jg3MUJgon5zfUaNoF5Be1ThDUiFrlzmpbOscPEdnQN /Yb6y+By900ZdOO5R+4NNs3dgFC6
X-Google-Smtp-Source: AG47ELs8IZDCGSnVoyLzUiMX4EnfoNaK8B/8a5zojL3y+N3EUJDeJnQ5qQDPqkgOtEXUF4Eop4aS/g==
X-Received: by 10.223.169.229 with SMTP id b92mr9212460wrd.244.1521465812384; Mon, 19 Mar 2018 06:23:32 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:65c2:adfb:a2b3:8eb4? ([2001:67c:1232:144:65c2:adfb:a2b3:8eb4]) by smtp.gmail.com with ESMTPSA id 4sm389401wmz.31.2018.03.19.06.23.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 06:23:31 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <883E9392-9163-4523-AB95-35738E27CE5D@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7DE87E3C-9A25-4C8B-B3CB-D4956117D197"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 19 Mar 2018 13:23:30 +0000
In-Reply-To: <87y3iottae.fsf@fifthhorseman.net>
Cc: Ion Larranaga Azcue <ilarra@s21sec.com>, "tls@ietf.org" <tls@ietf.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com> <6888195D-1AD6-45B1-8F77-AFA088CFF78A@gmail.com> <87y3iottae.fsf@fifthhorseman.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bv5x9G_Jnb9erau4aHfZcb0yWfg>
Subject: Re: [TLS] Breaking into TLS to protect customers
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: Mon, 19 Mar 2018 13:23:36 -0000

Hi, Daniel

Inline...

> On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor <dkg@fifthhorseman.net>; wrote:
> 
> On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote:
>>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue <ilarra@s21sec.com>; wrote:
>>> 
>>> I fail to see how the current draft can be used to provide visibility
>>> to an IPS system in order to detect bots that are inside the bank…
>>> 
>>> On the one hand, the bot would never opt-in for visibility if it’s
>>> trying to exfiltrate data…
>> 
>> The presumption is that any legitimate application would opt-in, so
>> the IPS blocks any TLS connection that does not opt in.
> 
> Thanks for clarifying the bigger picture here, Yoav.
> 
> So if this technology were deployed on a network where not all parties
> are mutually trusting, it would offer network users a choice between
> surveillance by the network on the one hand (opt-in) and censorship on
> the other (opt-out and be blocked).  Is that right?

I see it a little differently. Your computer or my computer, both of which are not configured to opt-in, should not be on such networks. In the corporate world, there could be a production network that enforces this and has access to corporate resources. There will usually also be a “guest” network with unfiltered connectivity, but no access to internal databases. This is where visitors go, but also where employee phones connect.

Of course the government of Elbonia might require all networks to have this feature, and then you’ll have to decide if you want to configure your laptop to opt-in.  I would prefer to stay off-line while I’m in Elbonia in that case.

> Designing mechanism for the Internet that allows/facilitates/encourages
> the network operator to force this choice on the user seems problematic.
> Why do we want this for a protocol like TLS that is intended to be used
> across potentially adversarial networks?

This is for hosts using network owned by the same entity that owns the hosts. When such hosts communicate outside this network, it’s for the leg of the connection that is within this network. I don’t see any use for it across an adversarial network.  If you trust it enough to give it your keys, it’s not adversarial.

> datacenter operators who want access to the cleartext passing through
> machines they already control already have mechanisms at their disposal
> to do this (whether they can do so at scale safely without exposing
> their customers' data to further risks is maybe an open question,
> regardless of mechanism).

I don’t think these mechanisms are currently available.  That’s a good subject for discussion.  If such mechanisms can be written without extending TLS, that’s obviously better.
> 
> Mechanisms that increase "visibility" of the cleartext run counter to
> the goals of TLS as an end-to-end two-party secure communications
> protocol.
> 
> Regards,
> 
>     --dkg