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

Watson Ladd <watsonbladd@gmail.com> Thu, 03 November 2016 17:30 UTC

Return-Path: <watsonbladd@gmail.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 F3E891296DB for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 10:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4v4a41vatYd5 for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 10:30:06 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829821296A1 for <tls@ietf.org>; Thu, 3 Nov 2016 10:30:06 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id 12so45459438uas.2 for <tls@ietf.org>; Thu, 03 Nov 2016 10:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lgemjt5YBAd+u8mbWbYzeJDUwp/fK7unWbu1GeM0qGo=; b=TbXavzb7CElcMuaZjM60abBUmEMVFWomFfkEA4m10PbWJHsIFfA7+YdCwN8aaQI48f 8Hg4J+P2Osvkwh/xpLka48W4WUxfms7qz0XpKn6R90iqVWf87kBcMp0i3Y2sa+13Fuag 96LLnOaAer5GDjbaw1yifzwrDCkhWMxo7HCyRcYTt9a/MRq6y4sFB6aJs/nVDQWx0gnH Pxb63DJmrZKUkSvHiEv76dZwzJEjJOItEMFH6mmSZkv/KsUEXQwkWOtElN4LWHYx+PNr vGo266/7mJUSdcsP2Cli5tL3vdc+/R+bZsGZH9MUy6Ga9RLcPhO1Rvwn/7X/soy+gEP8 ewvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lgemjt5YBAd+u8mbWbYzeJDUwp/fK7unWbu1GeM0qGo=; b=SUVhk4V6VJ93JePbPusGo71lH7e9BVWWGNTo9nFNuZ212xj2Q9sR3Vyy6ID9XXG32x jYgaCsYO6LhpQJ4WbRmkWV2bZEr8lcSLwFKqPVSgq1djtUf5ZCcsZvQaK3282ylj5Ou4 S2YoZtHigbBeKX5wXXHDS6rH1XKN2Sg8FHIDw7F/Yg3YMIZbjmqYPCHjZnxEQtY0IQNC 3iBGIHAoohdf7Mn96RYGgBY2T7phD4HtyjVhYx/bSU1+jTonxqogiZouDIAJeVekOyYr AE6jeqlVKYWoh3jiAp7nexgk0XaJuE+aRNdQ4xKH+6hFmGFsFrsNqOg0UwmUF5ro20t8 VQUg==
X-Gm-Message-State: ABUngvflEuFkfHPq9eyNtNYfdr50ZhhRRf4O5/lV4IIM1/HO8gTHs2BL5cmf3Dfj14XbuiLWbPNnLQD2YTfIpQ==
X-Received: by 10.159.37.235 with SMTP id 98mr5241721uaf.115.1478194205593; Thu, 03 Nov 2016 10:30:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.68.135 with HTTP; Thu, 3 Nov 2016 10:30:05 -0700 (PDT)
In-Reply-To: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp>
References: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi> <20161103143126.7B0F71A576@ld9781.wdf.sap.corp>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 3 Nov 2016 10:30:05 -0700
Message-ID: <CACsn0ckb67+w7d=_3iRVTxaKHZu=QkocqHC12E=ZX8+H5nZ=+Q@mail.gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/A7yLkc1KJO6KKrJOZR0wvy3xpg4>
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 17:30:08 -0000

On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex <mrex@sap.com>; wrote:
> Ilari Liusvaara wrote:
>>>>
>>>> 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_!
>>
>> 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).
>
> They WERE brought up back then, and several times in between.
> But the TLSv1.3 proposal has still not been fixed so far.
> Ignorance does not make problems go away.  Instead, it means that
> one will have to fix it later.
>
>
> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
> which has existed through SSLv3->TLSv1.2 would be a problem.  With the
> removal of renegotiation from TLSv1.3, it is even less of a problem to
> keep the contenttype in the clear.
>
> The removal of visibility of ContentType in TLSv1.3 will be a complete
> non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain
> software architectures (including a lot of stuff we've been shipping for the
> last 5 years), because it is actively being used to signal state of
> the communication channel to the application and to *NOT* break application
> architecture that relies on (new) application data remaining visible on
> network sockets as "network readable" events.

This I do not understand. I may make some technical errors in below,
and would appreciate correction.

I assume we have an application that is using poll() or select() or
somesuch for nonblocking IO (maybe something fancier, but that is
okay).

This application grabs data from a ready connection, rams it through
the TLS implementation, and then looks at what comes out. But reading
from the connection clears the data available state! However, it's
never the case that there is visible data absent a network read or
write after the handshake.

So what is the content type doing here? Does the application not call
a TLS implementation provided state function to determine what state
the connection is in? And if so why does the record layer need to
know, as opposed to the handshake one? I'm not seeing why the above
style implementation is impossible: Microsoft doesn't seem to think so
and hasn't complained about this change.

Sincerely,
Watson Ladd