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

Yoav Nir <ynir.ietf@gmail.com> Thu, 03 November 2016 18:38 UTC

Return-Path: <ynir.ietf@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 0E7ED129479 for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 11:38:41 -0700 (PDT)
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 aTEN3E4F2EqE for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 11:38:39 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 85DD51294A5 for <tls@ietf.org>; Thu, 3 Nov 2016 11:38:37 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id a197so5006869wmd.0 for <tls@ietf.org>; Thu, 03 Nov 2016 11:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GNJ85TEfBN5ksCAAI/yUWWI8Pr+9X94s9h9/NlOHKrg=; b=ooOjI81+1JGLbbEY4RtBeeBvU1QqsrPzQqMaeHpia31zfZATCYe71mTsuNHB8Qee+i sXRhCmyVTnhZVSqXhQNubxJTdDPwPk3txlcGunx5ylLnGlh3jeGSVnt4jbMUBPxB22Af MpZNZzCt2YS42lzxILuwB3SBfptEwp9CmX7TQs6vISiXOZjuzpsTSV30j33eV7syK6gL hUsO2Yo5Zb+GBYy4Fq2KeKwGCQWNdXkszYYfApB38WV2/dtH/xoO7EiVacBwycQdusBw 5yl+JcQstMoPY2kq8kbnGr5PPyAcWf1SXV1R3LBotXBN6WTm4SVK8jIwFmgcaOTNwYOD aB4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GNJ85TEfBN5ksCAAI/yUWWI8Pr+9X94s9h9/NlOHKrg=; b=h0R7pbo3qva9t61lv8Smf03vHOOtphjBkZqe+LfqaxNgh/yA1/ZqBl0qL2okycIYBJ ayzjvIk9Sex0QVHAVjFAE2g5vmkpfkjqtcaRExCZsLjYBWtZ0V16SURGeCa/qc2lFfcf BFzG/EYlEpKzh7sh++NyEs/Qzyl27xfx1sni9OPgp7+OKXmOH7juoVO+sPAK0IsDYJfu Ts+oiWJ0kCoIvl8Ryx+5zR6+kfiP0PPduZKfotkMUBGM8YZwpS8z9gvH/CY0HQ56t4Xv +sHllSy9qr/bC0SAfXp0sS+IW5FNLJ8lKqOuX0QaoXSJ5D4SDWI67bEqwxQDODupI/Jx PERQ==
X-Gm-Message-State: ABUngvdD8TVCn+yqQyY24K7KiFMUcS23b8JcBsDr1kn7o6weEMJE0F66Tx4cNrFzfVi54Q==
X-Received: by 10.28.27.133 with SMTP id b127mr1397622wmb.59.1478198316079; Thu, 03 Nov 2016 11:38:36 -0700 (PDT)
Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e5sm373206wma.10.2016.11.03.11.38.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 11:38:35 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_212CBCE1-010B-468D-B7F3-B69D28ECE908"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Thu, 3 Nov 2016 20:38:32 +0200
In-Reply-To: <20161103182046.34B541A576@ld9781.wdf.sap.corp>
To: mrex@sap.com
References: <20161103182046.34B541A576@ld9781.wdf.sap.corp>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nCKfe_2fJpl6flZlgCWhy1szH3g>
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 18:38:41 -0000

> On 3 Nov 2016, at 20:20, Martin Rex <mrex@sap.com>; wrote:
> 
> 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.

There is if you pad the records to the size of application records.

> (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.

Re-negoatiation doesn’t, but post-handshake client authentication does:
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 <https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2>

>     -- 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?

Yoav