Re: [TLS] Industry Concerns about TLS 1.3

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 23 September 2016 19:51 UTC

Return-Path: <yaronf.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 1200E12B775 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 12:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 AEPtOFQJPj_x for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 12:51:51 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 BF51D12B658 for <tls@ietf.org>; Fri, 23 Sep 2016 12:51:51 -0700 (PDT)
Received: by mail-pa0-x234.google.com with SMTP id qn7so25619883pac.3 for <tls@ietf.org>; Fri, 23 Sep 2016 12:51:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=T3Y2hfHw8AxzLIjOeciIoAdOcEQ/nnFnzmIn2NSdWD4=; b=o/N1wrb9d3le2t24NDm3qJ7wHC/HeU+D29tubNKdX7E8+UkPyDQamM1B8zKh1g9XoM q4cJ2ztnisezCSOGVoIMy0RvtFSkmQsyOazhnZ5p5MxR5mo5ad3IOmm0h2DTphR4M+ZR sya7o968QE4kyi4uKHwUvk2mtCPb0mfCGEYWnOcHN/Vv6ppnuePawLIWMb3oSzGdEjWX 3khchSYaPbRTT0I8QlU3JcYPgTiBbdAxHCJf6a3pdfGWxl7nKZj3LR11yeEOlZ4d+vDt 8UmnrHlTL4M1n50So16nIgD+oLDdyO9Uh5cAEvlQPubpoSpcWywahW36ko5qFPju7Syv OQQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=T3Y2hfHw8AxzLIjOeciIoAdOcEQ/nnFnzmIn2NSdWD4=; b=cjr8qK2N/ytqGqn+HcUSva3wJxTg3EligaUaagVRLqTHo87zULs8zdOXG6Vf9Ldt+f pkCm0tJxhNNEZk4p4KcmYHjw1PIVGx2lm7L5Ahdz0vGYVqqZRiS7qRh5fAR81ab/rxPd ibA0Ba1VO18Uzun0Iz4TbbgAnlhY0o+/3fM9WwRKhst+SNSSEP+JKGS6bFNVA2VmU2ol qoVGkp1PdmDuFlHEOBR/vn7C9ENijD3/vdLJC1Fr16RXq/up2zVDSIN47ltowHQgVFCp fWkKO5iJkQwWQesrZjCxVM3QSDHzYJ2NbvucPdpamAbEw0zMp4Y3BxK90STJ9FMJCrSD OkPQ==
X-Gm-Message-State: AE9vXwOtM6QeQu78UwRkjhFfUJxAjiXwm2XqJuH0OgJ6IMd76+em+FGv07tA0GlxQHFhWA==
X-Received: by 10.66.16.38 with SMTP id c6mr15274981pad.64.1474660311118; Fri, 23 Sep 2016 12:51:51 -0700 (PDT)
Received: from [172.17.207.2] (silverdollar.intuit.com. [199.16.140.26]) by smtp.gmail.com with ESMTPSA id xs10sm7374973pab.13.2016.09.23.12.51.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Sep 2016 12:51:50 -0700 (PDT)
To: BITS Security <BITSSecurity@fsroundtable.org>, Watson Ladd <watsonbladd@gmail.com>, "Ackermann, Michael" <MAckermann@bcbsm.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <DM5PR11MB141941D8E156245A1CF6C911F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Yaron Sheffer <yaronf.ietf@gmail.com>
Message-ID: <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com>
Date: Fri, 23 Sep 2016 22:51:45 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <DM5PR11MB141941D8E156245A1CF6C911F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gFSU1OSt873AWz7Er7Eo9qmAJ5A>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 23 Sep 2016 19:51:53 -0000

>> What exactly is the problem you are concerned with? As I've pointed
>> out previously one can still log the contents of TLS protected
>> connections: you do this at the client, or with an intercepting
>> proxy. What information does this not get you that you need on the
>> network?
>
> For enterprises using Content Delivery Networks, the TLS session from
> the browser ends at the edge server in the Content Delivery Network.
> The session that the enterprise sees is completely different:
> different IP's and ports, different TLS session, different
> application layer content because of caching, different network
> behavior (like packet drops and retransmissions).  If some
> infrastructure component in the data center is causing a problem, a
> trace on the browser side is blind to that.  An additional problem is
> that Microsoft does not allow logging of ephemeral keys in their
> browser.
>
[...]
>> From the time a packet enters a data center, it is travelling
>> through routers, switches, firewalls, load balancers, web servers,
>> app servers, middleware servers, and possibly hitting a mainframe,
>> all TLS encrypted for many enterprises.  Frequently, source and
>> destination IP's are NAT'ed multiple times, so there is no visible
>> relationship between the packet that enters the data center and the
>> same call at deeper layers of the infrastructure.  Any one of these
>> infrastructure nodes could be the cause of a problem.  The way to
>> isolate the fault domain of a problem is to take a packet trace at
>> each tier of the application infrastructure and look at the
>> application layer data in a decrypted trace in order to find the
>> transaction that is failing.
>

You are implicitly suggesting to remove perfect-forward-secrecy as soon 
as a TLS flow is created by the CDN. However these packets will still be 
traveling over the public Internet and/or "private" (leased, not really 
private) MPLS VPNs, where we KNOW that government agencies are 
eavesdropping and recording network flows to keep for years ahead. In 
other words, even when the TLS flow enters "your" network, you and your 
customer are still at risk from pervasive monitoring.

Thanks,
	Yaron