Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
"GUBALLA, JENS (JENS)" <jens.guballa@alcatel-lucent.com> Fri, 04 December 2015 12:52 UTC
Return-Path: <jens.guballa@alcatel-lucent.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C40E1B3116 for <tls@ietfa.amsl.com>; Fri, 4 Dec 2015 04:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgipGBYvbcse for <tls@ietfa.amsl.com>; Fri, 4 Dec 2015 04:52:20 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756031B3114 for <tls@ietf.org>; Fri, 4 Dec 2015 04:52:19 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id DE7C8BE94DC92; Fri, 4 Dec 2015 12:52:15 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tB4CqHQH004879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Dec 2015 13:52:17 +0100
Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 4 Dec 2015 13:52:17 +0100
From: "GUBALLA, JENS (JENS)" <jens.guballa@alcatel-lucent.com>
To: Bryan A Ford <brynosaurus@gmail.com>, Fabrice Gautier <fabrice.gautier@gmail.com>
Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: AQHRLbAt05dFICSaPkazPz5t63/sbZ66xIBg
Date: Fri, 04 Dec 2015 12:52:17 +0000
Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A04DF@FR712WXCHMBA13.zeu.alcatel-lucent.com>
References: <56586A2F.1070703@gmail.com> <FB2973EF-F16C-404A-980D-CA0042EC4AEB@gmail.com> <565DBC63.5090908@gmail.com> <547EE95EB794FD4DB8062F7A4C86D0BC4A39F163@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5660109C.7070803@gmail.com>
In-Reply-To: <5660109C.7070803@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0018_01D12E9A.FBDB7580"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/x1cKIBCyY2knewJhoQrY6asLPvU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 12:52:23 -0000
Hi Brian, > -----Original Message----- > From: Bryan A Ford [mailto:brynosaurus@gmail.com] > Sent: Donnerstag, 3. Dezember 2015 10:51 > To: GUBALLA, JENS (JENS); Fabrice Gautier > Cc: tls@ietf.org > Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 > after all? > > Hi Jens, > > On 12/2/15 11:47 AM, GUBALLA, JENS (JENS) wrote: > >> 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 4.1.2.5 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? > > Excellent question - I had intended to discuss that in my original post > but in the end forgot to include it. > > Indeed, with this approach as it stands, if every packet within a full > window of W consecutive packets fails to reach the receiver, then the > receiver has no way to resynchronize and the connection will simply > fail. In congestion-controlled protocols like TCP (or DCCP) that do > exponential backoff when they detect many consecutive losses, the > protocol may be more likely simply to hard-timeout than to reach the > W-packet resynchronization limit. But admittedly many UDP-based > protocols aren't (or are rather weakly) congestion-controlled, so this > may be more of a problem for them. It's probably the case that the > "forward-looking window" should be allowed to have a different value > from the "backward-looking window", and perhaps the "forward-looking > window" should depend on RTT (e.g., measured maximum packets-in- > flight). > > However, one way to eliminate this risk of permanent desynchronization, > at the cost of a bit more complexity in the receiver implementation > (though this needn't affect the protocol spec at all) is for the > receiver's "forward-looking window" to consist not of W consecutive > sequence numbers but a sparse set of sequence numbers at > exponentially-increasing distances. For example, if H is the current > highest sequence number, include in the forward-looking cache the > encrypted sequence numbers of the sequence number of the next multiple > of 2^1 beyond H, the next multiple of 2^2, etc., for as many multiples > of powers-of-two to get sufficiently far out in the sequence number > space where we're convinced there's no realistic chance of a run of > total or near-total packet loss unless it really means the connection > is > dead anyway. :) [JG] That would mean legitimate records would be dropped until an entry in the hash would match. Thus this proposal would potentially degrade the service, right? Basically I fail to see how a stream cipher can be operated reliable on top of an unreliable transport protocol. Best regards, Jens > > Again, these are all considerations that need not affect the protocol > but could be tuned by implementations (perhaps with some > recommendations > in the protocol spec). > > But regardless, all of this is just to make the case that header > encryption is in principle just as feasible in DTLS as in TLS, and > using > fairly similar techniques; right now I think we should keep the main > focus on whether to do it (at least) in TLS, for which is seems pretty > easy to do it in at least two different ways I've proposed. > > B
- [TLS] Encrypting record headers: practical for TL… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Tony Arcieri
- Re: [TLS] Encrypting record headers: practical fo… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bill Cox
- Re: [TLS] Encrypting record headers: practical fo… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Short, Todd
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Jim Schaad
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… John Mattsson
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- [TLS] Fully encrypted and authenticated headers (… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Fully encrypted and authenticated heade… Martin Thomson
- Re: [TLS] Fully encrypted and authenticated heade… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Mike Copley
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Stephen Farrell
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Ilari Liusvaara
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Mill
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Martin Thomson
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jeff Burdges
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum