Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 29 October 2016 14:22 UTC

Return-Path: <ilariliusvaara@welho.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 88D2112711D for <tls@ietfa.amsl.com>; Sat, 29 Oct 2016 07:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] 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 tW2vCx8K9KIg for <tls@ietfa.amsl.com>; Sat, 29 Oct 2016 07:22:33 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 63643127077 for <tls@ietf.org>; Sat, 29 Oct 2016 07:22:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id BFBC312CE3; Sat, 29 Oct 2016 17:22:30 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id d8jAf3-S1VPK; Sat, 29 Oct 2016 17:22:30 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6A7A2C4; Sat, 29 Oct 2016 17:22:30 +0300 (EEST)
Date: Sat, 29 Oct 2016 17:22:28 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20161028162426.GA25186@LK-Perkele-V2.elisa-laajakaista.fi> <20161028183545.942CC1A56E@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20161028183545.942CC1A56E@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Uun5uHd-BPBOeb3lYL87fi88I4Y>
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
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: Sat, 29 Oct 2016 14:22:35 -0000

On Fri, Oct 28, 2016 at 08:35:45PM +0200, Martin Rex wrote:
> Ilari Liusvaara wrote:
> > Martin Rex wrote:
> >> Joseph Salowey wrote:
> >> 
> >> There are two seriously backwards-incompatible changes in the
> >> current proposal that provide zero value, but completely break
> >> backwards-compatibility with existing middleware infrastructure.
> >> 
> >> 
> >> (1) hiding of the TLS record content types.
> >>     Please leave the TLS record types (handshake/AppData/Alert/CCS)
> >>     clearly visible on the outside of the TLS records, so that
> >>     middleware protocol parsers (which interface to transport-free
> >>     TLS protocol stacks) can continue to work, and continue to
> >>     work efficiently.
> > 
> > Hiding the types does have its benefits (and it is also used for
> > zero-overhead padding scheme).
> 
> Nope, ZERO benefits.  But it totally breaks the middleware
> _at_the_endpoints_!

Allowing padding is already a large benefit. TLS 1.2 AEAD modes don't
allow padding, causing rather large unavoidable information leaks.
Especially with HTTP/1.1, which doesn't have application-level padding
mechanism nor multiplexing.


Also, things like this should have been discussed like year or two
ago. Right now it is too late for major changes like this without good
cryptographic justifications (which AFAICT don't exist).

> > And also, TLS 1.3 handshake is so darn different from TLS 1.2, that
> > you couldn't do anything sane even if you had record types.
> 
> If one is using an architecture where the TLS protocol stack is
> transportless, so that the network communication can be performed
> efficiently (coalescing TLS records that are trickling in), then
> the *REAL* content type is quite important for knowing whether
> the TLS handshake is still ongoing, or whether it is already
> complete.

I implemented zero-copy (for TLS decoding) packet receving in TLS
lib I am writing. Works in both TLS 1.2 and 1.3.

Rather big efficiency boost too... I suspect doing the same for
encoding would be another big efficiency boost.

> The way I've built this is that the middleware has a timeout for
> the TLS handshake in its entirety (independent of the number of
> roundtrips), and at the same time promises the application a
> network readable event for every incoming TLS record with
> application data.  This only works if I can leave TLS appdata
> records partially in the incoming network buffer, and for this
> I must be able to recognize them.

Note that even if the record is truly appdata, it may not contain
any data, and one can't tell this from just the type.

> For processing TLS records with Handshake messages, pre-reading and
> passing multiple of them is preferable and much more efficient
> (if TLS handshake messages come in seperate TLS records each, which
> some implementations do).  Pre-reading TLS records with handshake messages,
> but not prereading TLS records with AppData (so that network readable
> events will remain visible for app data) is only possible if I see the
> contents on the outside of the record by just reading the TLS record header.

Also, TLS 1.3, it isn't safe to reorder appdata records across
handshake records, which can be sent after primary handshake
has completed.


-Ilari