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

Mike Copley <> Wed, 02 December 2015 15:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D792B1A00AC for <>; Wed, 2 Dec 2015 07:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N4vW8vIXYNPt for <>; Wed, 2 Dec 2015 07:15:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06B771A00C2 for <>; Wed, 2 Dec 2015 07:15:09 -0800 (PST)
Received: by wmec201 with SMTP id c201so258103283wme.0 for <>; Wed, 02 Dec 2015 07:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=usA1HGA3YumkjNBaYPVI8rwChgyYfrULLv5kMKjvWY8=; b=IRhiqW2DeBYIN0ext71R3R7u2nzWwQYnjKKakldWK6kTsTTzFzZNIDwQ3GaSaJJo1t HbzXQrKWFEYha8ICbUw6OO1qDf1cSAcRG+BeE1wKQ32GOea3lF499iakcnt8uWqwC63z sxMu+L3bh1ZOwQvH4UlHQ1dX6yGy+2khyjD17SDILZNGljM7UNUVtovGjncrFfBDQMmC dc+amrHeCZS0qrR6+Ha7oEbtcAQVBDfOEcBxhXtGZRsPg3n8c1vlCZyhj5bSMGuyeZ9j g0a23Tlsgfr6FE1bICOpg1bhoE0tA9LYJJmQjWeKKL+fzVZiui4hwex67z6TdFn5m2Qm pu9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=usA1HGA3YumkjNBaYPVI8rwChgyYfrULLv5kMKjvWY8=; b=Ficn4bHrdLaA8EPNFVMgcJWIeeQjWjqSmFJTBCrEGKuRn/pI0HgSjdOyi63RtV74st j+2pyIUFDPwwCiniDryWC7LjbHSGbY19KcChypOjynLpH0M2mSEDK60/JAHpUg+PCxFI NruITe2OP2a7GTZ23doS0ED5QSMQxEaRvVnxh16YZkNhwphiPxSrMMcP3zNH0rKtwo0r FU1lzl2Bl06UpA7U0zVikhkF8t0tFn2pSEOQxs3Pq5sSTnmWj+HzIFjIv2cwFrborahD qfKC55pyaFgS0VBxu5eksrU1IAAuQ7t8QmZZnvi8PYCnk0PTk388LsPFvvgvm5y4mxXE w58A==
X-Gm-Message-State: ALoCoQnEyj++IJC0tWxHPrqrzt3wFvbx5HlD1cu7bGRLOT6LSDPp62r6Rb1xMsgaTgOLXAsrQhQR
X-Received: by with SMTP id g69mr6320674wmi.97.1449069307592; Wed, 02 Dec 2015 07:15:07 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id a186sm3627409wmh.4.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 07:15:06 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Mike Copley <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 15:14:56 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Yoav Nir <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
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 15:15:11 -0000

On 2/12/2015, at 1:38 pm, Yoav Nir <> wrote:

>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <> wrote:
>>> These are corporate
>>> firewalls. When it comes to filtering HTTPS connections, firewalls have
>>> three ways to classify the connection:
>>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses.
>>> 2. #1, and additionally follow the stream looking for certain patterns.
>>> 3. Full “TLS proxy”.
>>> Whether they are relevant stakeholders or not is to me the same question as
>>> whether the network administrator in a corporate environment is a relevant
>>> stakeholder. We just make the middlebox that they deploy.
>> That is a kind of goal post shifting but seeminly weirdly not
>> relevant, if I understand. If it won't trouble the middle box, it
>> doesn't sound like the network administrator will have troubles.
>> It will however reduce off-path reassembly to technique #1 from above
>> and #2 will be partially eliminated and #3 isn't an option for that
>> attacker anyway.
>> We are working on solutions to #1, TLS 1.3 should reduce and if
>> possible, eliminate #2, and #3 is something that should require
>> consent of the user in question. Without consent, TLS 1.3 should hard
>> fail closed as a security measure.
> A TLS proxy requires user consent (or at least device administrator consent) with TLS 1.2. TLS 1.3 does not change that.

With SNI it’s possible to operate a transparent TLS proxy without the users consent. The proxy only has visibility of the SNI hostname - no user data (source: the company I work develops routers with such a proxy). It’s quite useful in hotspot/public wifi environments where making policy decisions based on hostname is more than sufficient, and explicit user configuration of proxy settings is a non-starter. As long as the SNI data is still available in the clear, encrypting subsequent headers won't impact the ability for our particular proxy to operate, as it’s just a generic TCP relay agent at that point.

With all that being said, I think the concerns about length hiding are better addressed through other means rather than header encryption. Not sure if this is the right place to consider, but would DTLS 1.3(?) be able to encrypt headers and still handle packet loss and re-ordering? If DTLS needs cleartext headers, would it be better to advise one approach for both protocols?


Mike Copley