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