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

Bryan A Ford <brynosaurus@gmail.com> Mon, 30 November 2015 08:56 UTC

Return-Path: <brynosaurus@gmail.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 0B0A61B2D18 for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 00:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bknooiUEA21z for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 00:56:09 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CE61B2D0E for <tls@ietf.org>; Mon, 30 Nov 2015 00:56:09 -0800 (PST)
Received: by wmvv187 with SMTP id v187so145300744wmv.1 for <tls@ietf.org>; Mon, 30 Nov 2015 00:56:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=kXt7uW0s/nOCAIEIG1LFbZEIZ/mBOpzeybAE59uCVWo=; b=Dw5PjAew2tksHmh+OGTsPaZc6MbjQwWgSbeyZG0TcKuCodv5jQLj0zc5z2jwPzyM/v Y3CPLcTCL6asu9BCEnRqjMvMA1pz1Qk6TJNVy1vhUXKsOCdFwuOgOrsZp4QSxIJMua4r cOf14A9Lk0Wf+QIFagA/jIDPw3pL6pNmSUSbcfGZkqW3kPg+Hky0b/BUUswhJUnkocox FbcDoWAxX5YQol/+Abz/RZoVbfnA6hqsmy1/Yz8xcEFCRciByqrP0UplHXtapQH2dTXg o9uMr5/q0TD7gDKQM4uU8GTeIVeRNjT3+X7V3ieyrTnOJk4z73fy1+61/a4tzR3BIEnu 18lA==
X-Received: by 10.28.48.213 with SMTP id w204mr24966510wmw.38.1448873767546; Mon, 30 Nov 2015 00:56:07 -0800 (PST)
Received: from tsf-476-wpa-0-088.epfl.ch (tsf-476-wpa-0-088.epfl.ch. [128.179.176.88]) by smtp.gmail.com with ESMTPSA id kc9sm12221852wjc.34.2015.11.30.00.56.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 00:56:06 -0800 (PST)
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "tls@ietf.org" <tls@ietf.org>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <565C0F25.7000507@gmail.com>
Date: Mon, 30 Nov 2015 09:56:05 +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: <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010708000107020700090804"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JKLlxNcNEiPpRzfIW87CkBuLEho>
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: Mon, 30 Nov 2015 08:56:11 -0000


On 11/30/15 2:26 AM, Peter Gutmann wrote:
> Bryan A Ford <brynosaurus@gmail.com> writes:
> 
>> Feel free to attack my proposal but then please attack *my* proposal, not 
>> the old broken SSH approach.
> 
> I was actually commenting on the concept of encrypting headers in general,
> not the specific case you'd given.  That is, I assumed you'd specifically 
> chosen the one case where it's practical, an AEAD stream cipher, and used
> that as a strawman.  Re-reading your post, it looks like "adding a stream
> cipher to every TLS 1.3-compatible ciphersuite" should really be "require
> that the only cipher type allowed for TLS be an AEAD stream cipher", 
> because it's not going to work with anything else.

In my proposal I focused on AEAD because I had understood (and thought I
had read in the TLS spec) that TLS had decided to move to AEAD-based
encryption in general.

I had no intention of implying that TLS "must" switch to AEAD
completely, and there's no reason it would need to for my proposal to
work.  It would work just as well and in exactly the same way if the
AEAD is replaced with the traditional Encrypt-then-MAC construction, for
example.

Also, if any issues with some (e.g., old) ciphersuites do arise, I
wouldn't object to specifying that TLS header encryption is done only
with "new" ciphersuites (e.g., the AEAD-based ones, or using some other
appropriate definition of "new").

Bryan