Re: [TLS] Update on TLS 1.3 Middlebox Issues

mrex@sap.com (Martin Rex) Tue, 10 October 2017 11:16 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 BE11C13449C for <tls@ietfa.amsl.com>; Tue, 10 Oct 2017 04:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level:
X-Spam-Status: No, score=-6.421 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, RCVD_IN_SORBS_SPAM=0.5, 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 9XaXqlZ1x2oP for <tls@ietfa.amsl.com>; Tue, 10 Oct 2017 04:16:05 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC05134CA6 for <tls@ietf.org>; Tue, 10 Oct 2017 04:15:56 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3yBF0W1lx0z1HHQ; Tue, 10 Oct 2017 13:15:55 +0200 (CEST)
X-purgate-ID: 152705::1507634155-0000088F-F65F4C40/0/0
X-purgate-size: 1872
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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3yBF0V4c25zGp0k; Tue, 10 Oct 2017 13:15:54 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9652B404A; Tue, 10 Oct 2017 13:15:54 +0200 (CEST)
In-Reply-To: <d9b27c27-4b6b-8d1c-38a7-d24ad34626e8@gmx.net>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com> <20171007091720.012fdb7b@pc1> <CAMfhd9W-=-b4V0tX74k=thE9J2Vet-RH7a-XzkxLutRMT2_5Pg@mail.gmail.com> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII> <20171010085226.54FF5404A@ld9781.wdf.sap.corp> <d9b27c27-4b6b-8d1c-38a7-d24ad34626e8@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Date: Tue, 10 Oct 2017 13:15:54 +0200
CC: mrex@sap.com, Ilari Liusvaara <ilariliusvaara@welho.com>, Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171010111554.9652B404A@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4RrgRDbrg1Dw5qzuOpqULYqM1K8>
Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues
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, 10 Oct 2017 11:16:08 -0000

Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> On 10/10/2017 10:52 AM, Martin Rex wrote:
>> Nope, none at all.  I'm _not_ asking for protocol changes, just that
>> the TLS handshake continues to end with CCS + HS, and ContentTypes
>> remain visible.  Contents of all handshake messages, and whether
>> and how that content is protected, remains subject to negotiated
>> protocol version which may vary significantly.
> 
> FWIW: Making the ContentType visible is a protocol change since the
> current version of the TLS / DTLS 1.3 protocol encrypts them.

I haven't looked at DTLS 1.3, but from what I remember TLS 1.3
has _two_ ContentTypes, one in the clear in the original TLS record
structure, and one encrypted, and the cleartext ContentTypes is
IIRC specified to contain bogus/misleading information.

Since hiding of the ContentType provides ZERO[*] security value,
fixing the cleartext ContentType to carry the true value is not
really a protocol change.

Conceptually, for the TLS *ENDPOINTS*, I prefer a code layering approach
with a transport-free TLS implementation by a huge margin.
Falling up and down huge callstacks with arbitrarily incomplete TLS records
results in huge amounts of complex, poor and inefficent code.

And the IO middleware layer should not have to bother with TLS protocol
versions.


-Martin

 [*] the security value of the hidden ContentType is zero, because
when capturing an entire TLS session, one will be able to
identify the real content types context-free heuristically in 99.5% of
the time looking at all records, and when knowing the server, one
can determine all the content types in 99,9999% of the time.

The hiding of the content type is only sufficiently awkward
to break streaming IO of communication layers above TLS, as well
as efficient connection state management.