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

mrex@sap.com (Martin Rex) Thu, 03 November 2016 18:20 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 C6F0B129AEE for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 11:20:48 -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 sAdUEtQ7_flO for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 11:20:47 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64A1129AED for <tls@ietf.org>; Thu, 3 Nov 2016 11:20:47 -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 smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t8tZ62V8Bz25yw; Thu, 3 Nov 2016 19:20:46 +0100 (CET)
X-purgate-ID: 152705::1478197246-00003836-B793CF6F/0/0
X-purgate-size: 1600
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 3t8tZ61smrzkyyn; Thu, 3 Nov 2016 19:20:46 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 34B541A576; Thu, 3 Nov 2016 19:20:46 +0100 (CET)
In-Reply-To: <C559BC1B-82C4-4349-B338-92DFC2D939C0@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Thu, 3 Nov 2016 19:20:46 +0100 (CET)
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: <20161103182046.34B541A576@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eIs_nAjhCISHSj1XD778svv1HQ8>
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: Thu, 03 Nov 2016 18:20:49 -0000

Yoav Nir wrote:
> 
> On 3 Nov 2016, at 16:31, Martin Rex <mrex@sap.com>; wrote:
>> 
>> 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.
> 
> Here?s some to get this to somewhat >0:
> 
> Most TLS 1.2 connections will have a few handshake records,
> followed by a couple of CCS records followed by a whole bunch of
> application records, followed possibly by a single Alert.
> 
> You only see more handshake records in two cases:
>    1. The client decided to re-negotiate. That is exceedingly rare.
>    2. The server decided a renegotiation is needed
>       so it sent a HelloRequest followed by a handshake.
> 
> With visible content type, you can tell these two flows apart.

 (a) so what?  for those interested, one can tell such flows appart
     pretty reliably by traffic analysis.  So there is exactly ZERO
     protection against bad guys, while breaking the good guys.

 (b) but TLSv1.2 remains unchanged, and this flow does not seem to
     exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3.
     -- 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.

-Martin