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

mrex@sap.com (Martin Rex) Fri, 28 October 2016 16:00 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 E390B129AB6 for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 09:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 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, SPF_HELO_PASS=-0.001, 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 jPf1hNmylM5N for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 09:00:06 -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 C1962129A6D for <tls@ietf.org>; Fri, 28 Oct 2016 09:00:06 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (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 3t57kX4H6Yz1JF1; Fri, 28 Oct 2016 18:00:04 +0200 (CEST)
X-purgate-ID: 152705::1477670404-0000521C-4101AA68/0/0
X-purgate-size: 1778
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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3t57kW5f1yzks98; Fri, 28 Oct 2016 18:00:03 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B5CA61A56C; Fri, 28 Oct 2016 18:00:03 +0200 (CEST)
In-Reply-To: <CAOgPGoChDnFf-4Vxm1S021MXHhGGpTjniD6+124B7off2RzO6w@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Date: Fri, 28 Oct 2016 18:00:03 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EsjS3DFETsWqufLvQbNlcyk1UBo>
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
Reply-To: mrex@sap.com
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: Fri, 28 Oct 2016 16:00:09 -0000

Joseph Salowey wrote:
>
> This is a working group last call announcement for draft-ietf-tls-tls13-18,
> to run through November 20. If possible, we would like to receive comments
> on the list by November 13 so they can be discussed at the meeting in
> Seoul. We hope to address any substantive issues raised during that process
> shortly thereafter.
> 
> In order to allow for cryptographic review, we will delay submission of the
> draft to the IESG until the end of January 2017; there will be an
> opportunity to address any issues discovered by the cryptographic community
> prior to submission to the IESG.


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.

(2) hiding of the TLS extension SNI.
    Right now it is perferctly fine to implement TLS extensions SNI
    on the server completely outside the TLS protocol stack to route
    to single-cert SNI-unaware backends.  The current proposal
    suggest to move TLS extension SNI into the encrypted part, if
    my superficial reading of the draft is correct, so TLSv1.3
    will not fly with existing architectures where spreading of
    TLS requests on the server-side based on TLS extension SNI
    is done outside of the TLS protocol stack (i.e. bottleneck-less
    without having to open TLS).


-Martin