Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

John Mattsson <> Tue, 01 December 2015 14:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 073891A92E2 for <>; Tue, 1 Dec 2015 06:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6h5luvhVn_Dm for <>; Tue, 1 Dec 2015 06:53:20 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD89F1A92DE for <>; Tue, 1 Dec 2015 06:53:19 -0800 (PST)
X-AuditID: c1b4fb30-f79296d00000141d-b4-565db45deb4b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 88.2F.05149.D54BD565; Tue, 1 Dec 2015 15:53:17 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 1 Dec 2015 15:53:17 +0100
From: John Mattsson <>
To: Yoav Nir <>, Hubert Kario <>
Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: AQHRLEgC9Fvj7xSjPUCCuObZgYMa+g==
Date: Tue, 01 Dec 2015 14:53:16 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7mW7sltgwg+UHtC1ufTvMavHpfBej xdJjH5gcmD12zrrL7rFkyU8mj/f7rrIFMEdx2aSk5mSWpRbp2yVwZVw8/4S14J58xaKn59ka GL/IdTFyckgImEicWLeAHcIWk7hwbz1bFyMXh5DAYUaJzQePgSWEBBYxSjy9WQNiswkYSMzd 08AGYosIuEj86NvBCmIzCyhKvL80jwXEFhYIkLjXsYsZoiZQ4lVDI1CcA8jWk+i+ZA0SZhFQ kTi3uosRxOYVMJdYvWUKI8TeDiaJAxf3gfVyCthK7G7bzwRiMwId9/3UGiaIXeISt57MZ4I4 WkBiyZ7zzBC2qMTLx//A7hEF2nXw00pWiLiixMdX+xhBbmAW0JRYv0sfYoy1xJKuuUww50/p fsgOcY+gxMmZT1gmMErMQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGRXmpRZnJxcX6e Xl5qySZGYFwe3PLbYAfjy+eOhxgFOBiVeHg/XIkJE2JNLCuuzD3EKMHBrCTC+3RtbJgQb0pi ZVVqUX58UWlOavEhRmkOFiVx3mamB6FCAumJJanZqakFqUUwWSYOTqkGxlUzHPda87+8s2Lf oWm73s65ll8X558fF8jRd+5BzdZVn9cr/l+ewC/5yI09IXeFk1is9GHDJRMqprx4+OZMbELQ +SNbLNkLLllsOdnaPom1tXV11PYrIU92C+ckm9wQ91TruPnKjJnLXsok4mbcT8nC3423F8tG 8eiEOelzSpfXK/zeIbDxlxJLcUaioRZzUXEiACSaCV/HAgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-Mailman-Version: 2.1.15
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: Tue, 01 Dec 2015 14:53:23 -0000

On 01/12/15 15:22, "TLS on behalf of Yoav Nir" < on
behalf of> wrote:

>On 1 Dec 2015, at 1:02 PM, Hubert Kario <> wrote:
>>>>> If you think it is practical for the TLS 1.3 standard to specify a
>>>>> single, fixed record size that all implementations of TLS 1.3 must
>>>>> use (i.e., explicitly freeze not only the version field but the
>>>>> length field), then that would be great for traffic analysis
>>>>> protection and on that basis I would support that proposal.  But
>>>>> that frankly seems to me likely a bit too much to ask given the
>>>>> diversity of TLS implementations and use-cases.  Tell me if you
>>>>> believe otherwise.>
>>>> That will just round up to a multiple of 256 bytes the data sizes
>>>> transmitted. Hardly an improvement over the current 16 byte blocks.
>>> Closer to 512 bytes is better.
>> Either hardly helps if you're not transferring packets with null data
>> really hide the amount of data transferred.
>I think this is not as black and white as you suggest.
>It is possible to totally hide the actual data stream by sending a
>constant-rate stream of constant-size data records regardless of the
>availability of actual data. This is a perfect counter-measure to traffic
>analysis but it has a huge cost in bandwidth. Endpoints who do that might
>well be considered to be DoS-ing the network.
>There are less drastic ways. You could add small variations to the timing
>and sizes of records, adding a little padding, splitting and combining
>the application writes, perhaps with the addition of the occasional burst
>of fake traffic. This can have a relatively small overhead and obscure
>the real sizes and number of requests. An attacker will still have an
>approximation of the amount of real traffic is actually passed, but would
>not be able to guess which Wikipedia article you are viewing or what part
>of the world you are looking at with your favorite maps website. This is
>not as perfect as the full traffic flow confidentiality above, but it
>would be more palatable to network administrators and to people who pay
>for Internet access by the megabyte.
>I don’t think this is the same as encryption where you either have
>perfect security or you have nothing at all. There can be incremental
>gains that are worth having at significantly lower cost than the perfect

While I support anything increasing privacy, I think a traffic flow
confidentiality mechanism should be optional to use (like in ESP RFC4303),
and not mandatory to use. The are still many use cases where where
bandwidth is not abundant, e.g. many wireless networks such as 2G, 3G,
802.15.4. Padding and dummy packets may significantly increase the number
of bytes. We should not end up in scenario where D(TLS) 1.3 is not used in
some scenarios because of an increase in overhead.