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

Yoav Nir <> Thu, 03 November 2016 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A01E1296DB for <>; Thu, 3 Nov 2016 10:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zv4DdSLcN9mA for <>; Thu, 3 Nov 2016 10:31:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20A92129AB4 for <>; Thu, 3 Nov 2016 10:31:33 -0700 (PDT)
Received: by with SMTP id n67so1123959wme.1 for <>; Thu, 03 Nov 2016 10:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2recxCWtM2ii5TY55+Wk02ajrb7VhIUphb8mhXbPb1A=; b=lvqk9fFsYwDXYzk0/DMn/RZpuw6fGf26VkFs+2cpjnm4Y4znPKmkFkVAn2cdRPGRwN NyGBvXpaz3iP/2HlxuMTurz5u+dmYi8tOA/FShklZWFE1PWZD+jnrLF8ovMgI5Nc7B4Q SzbxWvkLMQqv5bTz/lGa6agrzcGVoFfmLt6KR7EfdU9TBzU0pIwCaCfescyh1UV7oZbC lMWvy3kznCBjlMsWhaDECGKwj+ce+Qqi72iAxWHBcxsjt7BTaaQEr9kkzcGWcprbmBO+ GHkVu8ToGiNVzl6IfM8WQlge9dCwwfd25WieQeABM/tZ3Q1gadPVE3DxJmQ38AiRa/EM AS3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2recxCWtM2ii5TY55+Wk02ajrb7VhIUphb8mhXbPb1A=; b=nHT/n4RRJz8hllAlR6ZJ2FXsrm25rX83T1o1bf3ZI1ieApiefQXQEOqyaM8KTfG49B 6qsKJbt2wVOlVxpLv/WgKA4bKW3xNc3V8lPHuuhUDpDXH7f8hY6OdTnYk8+wN65Jygfq w1oMHVOoYKGphKiI/mWpGcwC7mTb0OZICD8Af8yqaLbqHKvfbdPPjKUsA+ERd2dmkWSi sAbxwYwL95G81EM8MXb3+g3mfBvB8rHKO2HGAaety2As76Xj1khcHqpoKyXE9zuH/xi7 b4qilK7fIv/mpCOnBMfUKyydvKDJDzzw+qJRSQqY5DVrimPu2dWnvI3J0kDfrmtz86r+ 2CeQ==
X-Gm-Message-State: ABUngvd+8vbI5mJwJsjHIqOm0zMWsDrTDjL8JOApE4uBU6leH0UhSrK2h08KC+KuqOeg3Q==
X-Received: by with SMTP id o6mr8929535wmg.124.1478194291440; Thu, 03 Nov 2016 10:31:31 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id z6sm761636wjt.24.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 10:31:30 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 03 Nov 2016 19:31:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.3251)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2016 17:31:41 -0000

On 3 Nov 2016, at 16:31, Martin Rex <> 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. What’s more, there is rarely any reason to do #2 unless the server decided that before accessing some resource, the client needs to present a certificate. You can verify that by counting the number and adding up the size of the handshake records. Having this happen usually means a privileged resource and a privileged user. That’s quite a bit of information to leak from a supposedly secure protocol. Yes, you won’t know the user identity, but you’ll know enough to associate privileged users with IP addresses, and you’ll know at what times they accessed privileged resources as opposed to something like a landing page. That’s meta-data, but it’s quite a lot of meta-data. If we can avoid leaking that, why not?