Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
mrex@sap.com (Martin Rex) Tue, 08 November 2016 15:26 UTC
Return-Path: <mrex@sap.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 DCBDF1295F9 for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 07:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 SNzs5AYrmlpj for <tls@ietfa.amsl.com>; Tue, 8 Nov 2016 07:26:02 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8761296F8 for <tls@ietf.org>; Tue, 8 Nov 2016 07:26:01 -0800 (PST)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3tCtS76yZlz25Wh; Tue, 8 Nov 2016 16:25:59 +0100 (CET)
X-purgate-ID: 152705::1478618760-0000521C-05015A4A/0/0
X-purgate-size: 3553
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3tCtS61vBDzkmmm; Tue, 8 Nov 2016 16:25:58 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 370F91A57E; Tue, 8 Nov 2016 16:25:58 +0100 (CET)
In-Reply-To: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Tue, 08 Nov 2016 16:25:58 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161108152558.370F91A57E@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rNyIDFzLJC9eN_nvtnUvXeaQYgY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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, 08 Nov 2016 15:26:05 -0000
Yoav Nir wrote: > >> On 3 Nov 2016, at 20:20, Martin Rex <mrex@sap.com> wrote: >> >>> With visible content type, you can tell these two flows apart. >> >> (a) so what? for those interested, one can tell such flows appart >> pretty reliably by traffic analysis. So there is exactly ZERO >> protection against bad guys, while breaking the good guys. > > There is if you pad the records to the size of application records. There is no such padding by default. And the TLS handshake is half-duplex, and for any interested third party, who performs the handshake with the server himself for comparison, the PDUs are still pretty much predictable heuristically (by their ordering), even when they're padded. So besides being completely pointless, can you describe any realistic problem that is worth breaking middleware at the endpoints so badly? > > > (b) but TLSv1.2 remains unchanged, and this flow does not seem to > > exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3. > > Re-negoatiation doesn?t, but post-handshake client authentication does: > https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 <https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2> > > > -- so why would we need a backwards-incompatible change in a > > protocol that protects something that no longer exists, > > but which severely breaks existing middleware, making it > > impossible to drop-in replace a TLSv1.2 implementation with > > a TLSv1.3 implementation that has this backwards-incompatibility. > > Can you elaborate on that middleware? As previously mentioned, it is middleware that facilitates using a TLS-protected communication channel for application callers. It offers several different kinds of reading strategies to the caller, which the caller is free to choose from. One reading mode is "streaming", where as many app-data TLS records are read (non-blocking) and decrypted, as fit into the application-supplied buffer. This facilitates communication with servers that fragment app data into pathologically small pieces (e.g. Google). Non-Appdata records (such as a final Close-Notify or a renegotiation request) are left in the network buffers, and will only be fully read&processed after all AppData preceding it have been properly returned to the application. In a similar fashion, the reverse proxy part (often in the DMZ), can check whether a browser prematurely aborts a communication and closes the network connection, by checking for readable events on the network socket and peeking whether it is a hard connection closure (TCP RESET, such as MSIE), or a CloseNotify Alert (Firefox,Chrome), without reading&decoding any application data. For large-scale Servers, non-blocking network operations are much more efficient than blocking network operations, the general wait point of the application is a select/poll call which waits on sockets, and it is up to the application to decide whether to "select for read" when it is ready to receive application data on a communication channel. With appdata records clearly distinguishable at the outer TLS record layer, the event-based architecture of the application did not need any changes when switching from cleartext communication to TLS-encrypted communication, all app-data socket-readable events remained visible with SSLv3->TLSv1.2, because TLS appdata records can be clearly distinguished from Handshake, CCS and Alert. -Martin
- [TLS] Working Group Last Call for draft-ietf-tls-… Joseph Salowey
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Sean Turner
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Daniel Kahn Gillmor
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Adam Langley
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Peter Gutmann
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… Yuhong Bao
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Thomson