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

Watson Ladd <watsonbladd@gmail.com> Wed, 09 November 2016 17:58 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 C6A4B12711D for <tls@ietfa.amsl.com>; Wed, 9 Nov 2016 09:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aYkUmXahL0MI for <tls@ietfa.amsl.com>; Wed, 9 Nov 2016 09:58:10 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 21421126579 for <tls@ietf.org>; Wed, 9 Nov 2016 09:58:10 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id p9so182421415vkd.3 for <tls@ietf.org>; Wed, 09 Nov 2016 09:58:10 -0800 (PST)
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=hDFpXzhn0f4JjxgmuutgWSHbvr/afNSsU5kedVE4pao=; b=wVjiHu3+yDBi5xboNmRZUxZBZ+C87eHB0BnAvi2K4b6v8FaJsABuYhwDsjQDFif4l6 8CWb/vvFhs6xzNfcWZxJhGX1A+6gWD91mrRwe1vXRfj+P8KeAnYU+31m0LFaxvdEVR+9 G+YV14bfE9fDLwh+017PbscAXft1Tjn1FjdG+/IRmbRxlFAkx4jQs8qhfqAMA3BIaDYS 3jsXhxuvKi9SkbOUm3+4CkXxonhStRhwi5u4Mxmj1fYTWF1G8vcHH2hCz2Q9fdb3A7u7 MXYmNrYBjnGgKUnOo1SnPDJevGEbFGmEByQxQZjcu6EcEfc4kyQLbTdy58f6j4n4QZYR 6+7g==
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=hDFpXzhn0f4JjxgmuutgWSHbvr/afNSsU5kedVE4pao=; b=aFsR1sKK80v44ROdEv3fn2csq7m23WitDmcSaZaKEJSU0Yg8clq3DuYUr2uOmcZt/t RDHL3b6oWX1z3XLFqWFpBYcMya3L8TPZ5sVwPUE2L+nLu3iRyRae7HkFQhApes7XNICS 2A8evMAr9ZI91eAcaEJsOye8w4q4T5YByMgqwt1caRNxZaO0Ac1AWiCyrA7HaJ2m5SHK doMGI+RgJttoFeTJDuerGLL6s4LuNEU5+PL7O2EHoFto5XBAq1zEpcve04SiR5QsRzw9 c58KkDkZbmYCbYXsZh5C7mwvMi9pvTdLCZaIV/vvcHXcyWpVRfxdhjq3+C0tq5P2QcIB tpcg==
X-Gm-Message-State: ABUngveSVbGUV1g00eD8nJxSmBwbmZzrAGn7v17BPe0YWnX3JuHUi+cQWoWZy2Ts/KBxdALCKQLxAJgXh3mDwg==
X-Received: by 10.31.178.66 with SMTP id b63mr605307vkf.70.1478714289150; Wed, 09 Nov 2016 09:58:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 09:58:08 -0800 (PST)
Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 09:58:08 -0800 (PST)
In-Reply-To: <20161109174219.454D21A579@ld9781.wdf.sap.corp>
References: <87inrweg88.fsf@alice.fifthhorseman.net> <20161109174219.454D21A579@ld9781.wdf.sap.corp>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 9 Nov 2016 09:58:08 -0800
Message-ID: <CACsn0cmSKTEt6yXtAL2qbOiLSjAB3TBC8wY0Yysowe8w2nDkTQ@mail.gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a11439232ede74e0540e1ff40
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MpRCZB8prjm9lk6TKTqTTWogHbo>
Cc: 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: Wed, 09 Nov 2016 17:58:17 -0000

On Nov 9, 2016 9:43 AM, "Martin Rex" <mrex@sap.com>; wrote:
>
> Daniel Kahn Gillmor wrote:
> >
> > Martin Rex wrote:
> >>
> >> The problem here is that this breaks (network) flow control, existing
> >> (network socket) event management, and direction-independent connection
> >> closure, and does so completely without value.
> >
> > Martin, you keep saying things like "without value", while other people
> > on this thread (Rich, Ilari, Yoav) have given you examples of the value
> > it provides.  You don't seem to be trying to understand those positions.
>
> Nobody so far has provide a single example of *REAL* value.
> For the hiding of ContentType to provide real value, the prerequisites
are:
>
>   (1) this value will be _unconditionally_ provided in TLSv1.3
>
>   (2) this value can be demonstrated to be a real security issue in
TLSv1.2,
>       for existing usage scenarios, where hiding of ContentType is not
>       available
>
> Anyhing less is no value, just an illusion of value.
>
>
> >
> > This WG isn't chartered to defend the engineering optimizations made by
> > any particular middlebox vendor.  It's chartered to improve the privacy
> > and security guarantees offered to users of TLS.
>
> You are confusing _middlebox_ with _middleware_at_the_endpoint_,
> which is a huge difference, because the middleboxes are performing
> man-in-the-middle attacks, whereas the _middleware_at_the_endpoint_
> has regular access to the entire plaintext of the communication.
>
> The problem with hiding of TLS record ContentTypes is that it severely
> interferes with efficient streaming network I/O--which is preferably
> performed outside/above the TLS implementation and async non-blocking
> whenever you get into thousands of parallel connections.

No one else has reported this. That's including Microsoft whose
implementation does hand over all IO to the application. Absent many more
details you are not convincing me there is a problem.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls