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

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 03 November 2016 19:02 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 E2ABA12978B for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 12:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 LpoMM2D8hKGy for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 12:02:13 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 727A7129AB3 for <tls@ietf.org>; Thu, 3 Nov 2016 12:01:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AE4631602E; Thu, 3 Nov 2016 21:01:29 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id V6dDmY80X78X; Thu, 3 Nov 2016 21:01:28 +0200 (EET)
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-smtp2.welho.com (Postfix) with ESMTPSA id 702A521C; Thu, 3 Nov 2016 21:01:28 +0200 (EET)
Date: Thu, 3 Nov 2016 21:01:26 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <20161103190126.GA11294@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20161103182046.34B541A576@ld9781.wdf.sap.corp> <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ntb6zY1m5apit7cFmbBRfvizTgk>
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: Thu, 03 Nov 2016 19:02:16 -0000

On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote:
> 
> > On 3 Nov 2016, at 20:20, Martin Rex <mrex@sap.com>; wrote:
> > 
> >     -- 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?

Also, what platform (Java? .NET? Linux?) does that middleware run on,
and some base interfaces from standard library (or widespread
extensions) it uses for its API...


What I think I gathered from the description (and this sounds very
bizarre):

- Upon new data indication, the middleware peeks TLS header from the
  incoming data buffer.
- If it is not appdata, it is read and handled.
- If it appdata, the socket readable indication is passed to the
  application (what supports that without wrapping the socket???)
  which it then reads (and presumably passes for decryption).


That sounds much more bizarre than the zerocopy APIs in btls (the
TLS lib I am working on), and those are already pretty odd.


-Ilari