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

Benjamin Kaduk <> Thu, 03 November 2016 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F0E4129463 for <>; Thu, 3 Nov 2016 11:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RgVwtVaONG9s for <>; Thu, 3 Nov 2016 11:33:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 767BD1200DF for <>; Thu, 3 Nov 2016 11:33:17 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id 6CE094334FC; Thu, 3 Nov 2016 18:33:16 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 4CBED433401; Thu, 3 Nov 2016 18:33:16 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1478197996; bh=4m0xZ7QcjJPOQLNv+bRkA36388QWdg48reRP6e4+liM=; l=3949; h=To:References:Cc:From:Date:In-Reply-To:From; b=B9uofTPxPAYACdYc+C0FlK0lKL9nRBv4+JFW2jpZvISy/xbaxA9cmVEtc4L7koMU7 NeaOIhO21HzIJDqaElxjCFbzeHEA0byvea+pNllQDL1+R++sVx/XBgvj1PaxTWx4Xt AhUPKqsdObZC6DwQsYiKSiJRpLdd0mL59fNMy+R4=
Received: from [] ( []) by (Postfix) with ESMTP id 1188D1FC88; Thu, 3 Nov 2016 18:33:15 +0000 (GMT)
To:, "Salz, Rich" <>
References: <>
From: Benjamin Kaduk <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 03 Nov 2016 13:33:15 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------878E34758B5DE5DAC98CCDDE"
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 18:33:19 -0000

On 11/03/2016 01:15 PM, Martin Rex wrote:
> Salz, Rich wrote:
>>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>>> which has existed through SSLv3->TLSv1.2 would be a problem.  
>> Because it's kind of implied in the charter, about making as much private as possible.
>>> years), because it is actively being used to signal state of the communication
>>> channel to the application and to *NOT* break application architecture that
>>> relies on (new) application data remaining visible on network sockets as
>>> "network readable" events.
>> One app's data is another adversary's oracle.
>> Or is it that "signals have no morals"?
> If you look at TLS records exchanged between two peers,
> and in particular if you perform a TLS handshake with same server
> yourself and compare, you can easily (heuristically) determine
> which TLS records of the original stream are hanshake records,
> and which are application data records.
> So there is exactly ZERO benefit of concealing the ContentTypes.

Sorry, but that doesn't directly follow. 

With visible content type, an observer can *trivially* tell apart the
two flows you mentioned in your next message.  With current stacks'
(lack of) padding and timing obfuscation, the observer can still tell
the flows apart ... but you have a chance of writing a stack that
prevents the observer from doing so.  I don't think that "goes from
'impossible' to 'you have to write code'" can be construed as exactly
zero benefit.