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

Bryan A Ford <> Tue, 01 December 2015 15:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00EE11AC444 for <>; Tue, 1 Dec 2015 07:27:39 -0800 (PST)
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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HH1sQzg_0VOv for <>; Tue, 1 Dec 2015 07:27:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1DCE1AC442 for <>; Tue, 1 Dec 2015 07:27:36 -0800 (PST)
Received: by wmvv187 with SMTP id v187so212229095wmv.1 for <>; Tue, 01 Dec 2015 07:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=q78zUr0/Mjm/tQ3/E9wm18sCarLKwKfA6ITVDtve0nU=; b=YQcqBxsc0+Dy8IJSwA5GdXleyszuQJy2rYaHW+Y7wuOW4mZj7HWVJ+Ukqt/H4Z7jSj 0YsA8VB7O6rexGcO9PNnZ89CgxX40nfgBE9CG9aoEjqQ90NDM+3Zcqiae5EEozRIdGCj pfMQ6GKBaLAqEH5Py+bGkmZF7G8QS1ko+iYImnAWA4baRGB81ypqjurUqWPoghFPInQ4 IJ3SHymUsGViY5qSIBP5cXmWtzaTrHVMiwq0fNK21SifMCXIU+i5rqGbxjXukVkBVhKs Fm3Qof9ifGsnrizumkiJf8gQQ4J2wR7qJwqFom1OJdkoYElZxL7EmWfUeqFCV980tcz2 ZvaA==
X-Received: by with SMTP id uq6mr58397862wjc.126.1448983655322; Tue, 01 Dec 2015 07:27:35 -0800 (PST)
Received: from ( []) by with ESMTPSA id b84sm26626852wmh.15.2015. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 07:27:33 -0800 (PST)
To: Fabrice Gautier <>
References: <> <>
From: Bryan A Ford <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 01 Dec 2015 16:27:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020207040308070106040506"
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 15:27:39 -0000

On 12/1/15 4:02 AM, Fabrice Gautier wrote:
> 1) What would be the implications of this for DTLS? (Knowing that one difference between TLS and DTLS is the record header)

Good question.  Fortunately my proposal should be fairly easy to adapt
to DTLS, with one small trick.

The main issue is that DTLS packets need to contain explicitly
transmitted sequence numbers rather than implicit sequence numbers,
because packets can be received out of the order and the receiver needs
to know which sequence number (and hence which nonce) to use to try to
decrypt and integrity-check.  But if we encrypt the full DTLS header
including sequence number, how does the receiver decrypt it without
knowing the correct nonce to use to decrypt it?  An apparent
chicken-and-egg problem.

Fortunately the solution is fairly simple: the receiver simply
pre-computes and keeps in a small hash table the encrypted sequence
numbers of all packets with sequence numbers between H-W and H+W, where
H is the highest sequence number correctly received so far (the horizon)
and W is the anti-replay window size as specified in of RFC
4347, which typically should be 32 or 64 according to the RFC.  The
receiver can precompute all these encryptions because in my proposal TLS
headers are encrypted with a stream cipher (or the AEAD operating as a
stream cipher), so it's just a matter of producing the correct
cipherstream bytes and XORing them with the uint48 sequence number.

Whenever the receiver gets a datagram, it looks up the encrypted
sequence number in the hash table, drops it on the floor if it's not
present, and if it's present the receiver gets the decrypted sequence
number from the hash table and uses that in the AEAD decryption and
integrity-check.  In the low-probability event of a hash-table collision
(i.e., two uint48 sequence numbers encrypting to the same 48-bit
ciphertext in a single 129-datagram window), the receiver can
trial-decrypt with both (or all) sequence numbers in that colliding hash
table entry.  Or the receiver can keep it even simpler and just drop all
but one colliding entry, introducing a pretty low probability of
introducing occasional "false packet drops."

The hash table is pretty trivial to maintain efficiently as well: e.g.,
whenever the horizon H moves forward by delta D, remove the first D
entries from the current window and precompute another D encrypted
sequence numbers (where D will most often be 1).  In the simple design
that doesn't bother dealing with hash table collisions (e.g., that
allows each hash table entry to contain only one value), perhaps don't
even bother clearing/removing old entries; just gradually overwrite them
with new ones as H moves forward.

> 2) In some implementations the record framing/parsing and encryption/decryption are down at different layers. Would this proposal make this type of implementation impossible? 

Not that I'm aware of, but I might need more information about the
specific layering approaches you're thinking of and how "strongly
enforced" that layering might be.  But in the version of my proposal
that operates the "normal" AEAD as a stream cipher for header
encryption/decryption purposes, it doesn't seem like any change would be
needed to the standard AEAD encryption/decryption interface.  It should
even be fine if the AEAD was implemented as a separate hardware module
that takes the standard AEAD interface inputs and produces the standard
AEAD outputs; as long as it supports the standard AEAD API it should be
perfectly usable in the design I proposed.

The one potential issue I can think of if a particular, restricted API
forces the caller to commit at key-setup time to either "AEAD encryption
mode" or "AEAD decryption mode", and makes it difficult or impossible to
switch back and forth.  In that case in my proposal as it stands the
receiver TLS implementation might need to set up and maintain two
hardware contexts, one for AEAD decryption (for the payloads), the other
for AEAD encryption (for stream cipher header decryption), both using
the symmetric key.  This still doesn't seem all that problematic to me,
though, and I don't even know of any particular APIs offhand that
present this particular issue.