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

"GUBALLA, JENS (JENS)" <> Wed, 02 December 2015 10:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5CC9E1A878A for <>; Wed, 2 Dec 2015 02:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yDZPy9HKucz9 for <>; Wed, 2 Dec 2015 02:47:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EA131A8778 for <>; Wed, 2 Dec 2015 02:47:26 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id A6DD09D66FC3B; Wed, 2 Dec 2015 10:47:22 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id tB2AlL7B003252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Dec 2015 11:47:23 +0100
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 2 Dec 2015 11:47:07 +0100
To: Bryan A Ford <>, Fabrice Gautier <>
Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: AQHRLEzU2k6BjHO6ykivH825T94vhJ63f/ig
Date: Wed, 02 Dec 2015 10:47:06 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0223_01D12CF7.2AF664B0"
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 10:47:28 -0000

> 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.

[JG] In case there is a packet loss of at least W subsequent DTLS records: 
How can the receiver then ever adjust its hash table? Wouldn't that mean 
that no records at all would be accepted anymore?

Best regards,