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

Peter Gutmann <> Wed, 02 December 2015 23:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BAFEC1AD0B9 for <>; Wed, 2 Dec 2015 15:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qO0_ztXlZXhX for <>; Wed, 2 Dec 2015 15:36:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE7781AD0AF for <>; Wed, 2 Dec 2015 15:36:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1449099364; x=1480635364; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jBE+p2+HyCwZyuDsik4rTDwgy4fc8z+GXgOW4x6zYmU=; b=hwvG+Z/H9wrSu1JR6O9aQUQVWh/s3Po84LPQSSd+xPmX8O6jaWwT1Edt 3NJrMZeKfsAXZk0ZwjBXCPdCfzbTtgFgrnvuHq4gRp7AJIe3hUADhgxML PBq6vneY9ZUZVDrEAV/rg6ftbZiZmoEwdPaVpY8P9w7+kpFq+Py3FZTMP 5G0ZkPNfztgfGIAOPaRluTN+tkwjHcdIY3XB/exwuJMfIo66sIe59eX72 le3BLjknQZma8/VAOMsygGgVPClsnyi4nsPL+r0O9duQaQ8pT2yA/ri+c JXsGP1aLxQVI33fvylBx5Ac8rKq8bUPecNxRgNHQtMUBL5pV8y6oXwJnQ Q==;
X-IronPort-AV: E=Sophos;i="5.20,375,1444647600"; d="scan'208";a="57330855"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 03 Dec 2015 12:36:01 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Thu, 3 Dec 2015 12:36:01 +1300
From: Peter Gutmann <>
To: Bryan Ford <>
Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: AQHRLOi8exSx9f5oS0GRoAMeoC+Kxp64WmlC
Date: Wed, 02 Dec 2015 23:36:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 02 Dec 2015 23:36:07 -0000

Bryan Ford <> writes:

>We have repeatedly stated several relevant threat models here; you just 
>don’t seem to be accepting them as threat models for some reason. 

That's because they're not actual threat models, just handwringing about
vague, undefined bogeymen.  Yoav Nir has made a good start, although it's
more a wish list than a threat model, or at least a list of desirable 
properties for the system to have.  In crypto terms, it's like stating
"I want my cryptosystem to be IND-CPA".  The threat there is an adversary
being able to encrypt various plaintext messages and being able to 
distinguish them based on the ciphertext.  You can pretty clearly say
that against this threat (stage #1 of my list), you need an IND-CPA
ciphersystem (stage #2).  From there you can decide whether it's worth
doing this, stage #3 (OK, any cryptosystem worth its salt had better be 
IND-CPA, so that's a tautology).

OTOH an IND-CPA cryptosystem isn't necessarily secure against an
adative chosen ciphertext attack, a different type of threat, so you 
need to up the defence to an IND-CCA2 secure system.

Give me an actual threat model of the type(s) illustrated above, write 
down the exact capabilities of the attacker so we know what to
defend against, and then we can disagree on it.

>We have been doing this as well, repeatedly. 

No, you've just been saying "here's my pet idea, TLS should adopt it"
over and over again.  I'm happy to keep saying "it doesn't provide
the protection you seem to think it does, it restricts TLS to only
using AEAD stream ciphers, and it causes serious headaches for
implementations" as often as you keep repeating "here's my pet idea,
we should use it".