Re: [TLS] The case for a single stream of data

Roland Zink <roland@zinks.de> Tue, 09 May 2017 17:30 UTC

Return-Path: <roland@zinks.de>
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 B93E8129BA4 for <tls@ietfa.amsl.com>; Tue, 9 May 2017 10:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 5DoR6uno9kDy for <tls@ietfa.amsl.com>; Tue, 9 May 2017 10:30:42 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939AA129C1E for <tls@ietf.org>; Tue, 9 May 2017 10:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494351039; l=1602; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=4I8JnOGKnxaZ+vkqcWJjNDaAPFLgIGDU0bxRSQJzDxw=; b=F02EhvfpE3QCNXZYf49bevl77qpcVQp8KD0T4xzqkeoId/umSJaiVO2zXd7i6GIWGd BsNhWd/X8FEhlhdMnvcebQWcxQGI3Dn0hNopKgWmJNUiTLog5X8B/bV+JSnc067DW8eY F1GoQ0EP5AcPlrvlW0PjYMUg5lF5oU7ghUdkU=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWW4p8jDXe5M9gWO76GPk
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p57B96B9B.dip0.t-ipconnect.de [87.185.107.155]) by smtp.strato.de (RZmta 40.6 DYNA|AUTH) with ESMTPSA id n06cc1t49HUcnI8 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Tue, 9 May 2017 19:30:38 +0200 (CEST)
To: tls@ietf.org
References: <CAAF6GDfm=voTt_=JrdGtiaYby1JG8ySU2s6myjjpHKeGvi0bMg@mail.gmail.com> <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcGQ0YTYFFD+HVD71O9GCW7V3r_UNce1LQsHF1Zs9aBLQ@mail.gmail.com> <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <5a5e0448-1b1a-1b92-e22b-f4c095f2bfbd@zinks.de>
Date: Tue, 09 May 2017 19:30:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fvb85KYwsMxN4PJFECI8PxCI2hc>
Subject: Re: [TLS] The case for a single stream of data
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, 09 May 2017 17:30:45 -0000


Am 09.05.2017 um 18:41 schrieb Salz, Rich:
> The second problem is that middle-boxes can break any signaling. For example a CDN or TLS accelerator may enable 0-RTT towards the back-end origin without enabling it to the original client. In this model, the client has *no* way to reason about retries or replay.
> A CDN is not a middlebox.  As far as the client is concerned a CDN *is* the origin.  The agreement in-place between the CDN and the origin is out of scope here.  A TLS accelerator, which is a tool to help an origin with its *local* performance, or other lower-layer (in the L3 L5 etc sense) assist is within scope.  Does that make sense?

Depends on how you look on this. For TLS the CDN is the origin. For an 
end user the CDN is often a third party which means some unknown 
entities get access to potential private data. When this is on another 
country this may include foreign official entities in addition to the 
3rd party company itself. Really bad is when the user is not informed at 
all, e.g. the page URL doesn't show the CDN (or ad or tracking) company. 
For a mass surveillance just monitor a few tracking, advertising or CDN 
companies and you will get most of the URLs (refer header) and more from 
most users without breaking the TLS security. So why do TLS at all?

>> That's really very broken and a serious violation of the transport layer contract.
> Only if you believe CDN is a middlebox.  The transport layer contract is overridden by legal contracts or EULA :)
>
> 	/r$
I would prefer if TLS wouldn't allow 3rd parties without user notification.

Roland