Re: [TLS] Breaking into TLS to protect customers

Colm MacCárthaigh <colm@allcosts.net> Mon, 19 March 2018 14:20 UTC

Return-Path: <colm@allcosts.net>
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 A717D12D877 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 07:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 ToQZ3x1QdjXL for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 07:20:06 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 6B1911277BB for <tls@ietf.org>; Mon, 19 Mar 2018 07:20:06 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id l200so11479439ywb.0 for <tls@ietf.org>; Mon, 19 Mar 2018 07:20:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wi9LOVaPxz2RTTbf61SBpa38QbQFhvDUU/2Yr0gsMvw=; b=j+Eqz62BD905DpA33q4lUgjwbMPoP9FNKGqLIg9CXZptnL4tawajPEhZgBgkhRVqxR 8H02L+0UsZ4Trr0CXK8VoVKQPHf63/o2Xz61eWkZwanD0gnx/6gnvfuiV/syL8sd1jxQ La9EPUtDSHU8XPF4cM7JwIIYBsPEh9SnKA/tnKs8w5L6rl+mzauOflxRyamuVjV/Ne2J Nbem/3BloNnaR3FwdaiwyjNmuM9TorcLZMrv6vRl9HuLCTrfkZihC17pdQp2LEItoERY RGbNib06T7gFQEs9eq4UZgpVLWzzwKRYbb/HiM7kqVDM4y5pzf89XL2cIfqgwwSv4kKO +7tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wi9LOVaPxz2RTTbf61SBpa38QbQFhvDUU/2Yr0gsMvw=; b=eGmklCLfb+TLvV00CL7H2amOzTUWr+u7VVWXtCopWV7RbyxbbKCZBy+RzDdfSjS10o Q6vozhNsVOCxDDaYBWOmYSDxPcq9GQ4613SCvitS7J2dgrrukpuGbsjnMuEuDTSh70Oc s/ndk0e2hCKIIGftDhkeTA0U5fjZYOcEmMObSOvcYrre/VWAzLNk8+A1s13fK0pmiQ5W V7Yg724BjLc3+l8F1x0aYu+Ln5YrXd+FRBt0h/MBCH+4g92fArOsgbJJaAx6Q4O2Zx8Y sU9RHdFbDOWz4Zxf6XBGxFE3TchBrwPxBirvMs6Q++IGBVsQNZpDCcGzXN3Y6KBfqRlc 4lTg==
X-Gm-Message-State: AElRT7GKoEU7IQ6S9nuExVW+DK98UQArQ8DfWpennVsGRtCJ7YrQmxwl QftAIVx7mAyTvxW/iqwIPRyQiz6KTRz36NVEfkz2SQ==
X-Google-Smtp-Source: AG47ELuDutt5LcYX4kheHypOFt4JFhQnxKco5nuQxSJd/hbv2w1V1a/gPnqtyCO33ABFgP8VTM7WhjfgIYKCTH/2YpY=
X-Received: by 10.13.252.68 with SMTP id m65mr4152668ywf.315.1521469205469; Mon, 19 Mar 2018 07:20:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.108.203 with HTTP; Mon, 19 Mar 2018 07:20:04 -0700 (PDT)
In-Reply-To: <87y3iottae.fsf@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>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Date: Mon, 19 Mar 2018 07:20:04 -0700
Message-ID: <CAAF6GDeAOKtCF5BhfyG6wEd5L-mevKeuDMM1AmgdGKyfuEyzdQ@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Yoav Nir <ynir.ietf@gmail.com>, Ion Larranaga Azcue <ilarra@s21sec.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c064ede8776130567c4a725"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RObOP8WuzAxNdkcobiiFRB8UAzw>
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 14:20:19 -0000

It's true that breaking open cleartext runs counter to the mission of
end-to-end TLS, but it also seems like operators are going to do it if they
can. Whether by staying on plain RSA, using static-DH, MITM through
installing a private trusted CA, or exporting session secrets, they can
certainly do it.  I worry that we'll lose a good opportunity to improve the
security and transparency of things by turning our nose up at that.

Here's a straw-man suggestion:

Suppose we took on a draft that adds a new optional handshake message. The
message could go immediately before FINISHED, in either direction (or
both), and contain an encrypted version of the soon-to-be-session-key.  For
back-compat: it could be encrypted with RSA, or whatever else the endpoints
want to support. This is basically what STEK encrypted tickets look like
today with TLS1.2 anyway, though usually with symmetric encryption, so it's
not that wild a departure.

Obviously this breaks forward secrecy, and allows passive tapping and
session hi-jacking, but then that's the point. But I think there are some
security advantages too:

1/ By making the functionality part of the handshake transcript, it is
unforgeably evident to both sides that it is happening. The proponents of
this functionality claim that everything is opt-in, but this gives some
cryptographic teeth to it.

2/ clients and browsers could easily consider such sessions insecure by
default. This would mean that adopters would have to deploy configurations
and mechanisms to enable this functionality, similar to - but beyond - how
private root CAs can be inserted.

Wouldn't those be good properties to have? Compared to servers secretly
exporting transcripts or session keys, or just having a private root CA
installed which breaks all sorts of certificate verification
infrastructure?

I think the existence of a "standard" here could also serve to encourage
providers to do things the more transparent way, and create less likelihood
of a mass-market of products that could also be used for more surreptitious
tapping.


On Mon, Mar 19, 2018 at 12:32 AM, 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?
>
> 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?
>
> 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).
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
Colm