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

Dave Garrett <davemgarrett@gmail.com> Sun, 29 November 2015 21:47 UTC

Return-Path: <davemgarrett@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 ABF071B3542 for <tls@ietfa.amsl.com>; Sun, 29 Nov 2015 13:47:20 -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 8hX1IVqADGok for <tls@ietfa.amsl.com>; Sun, 29 Nov 2015 13:47:19 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 2AB511B3541 for <tls@ietf.org>; Sun, 29 Nov 2015 13:47:19 -0800 (PST)
Received: by qkao63 with SMTP id o63so52497282qka.2 for <tls@ietf.org>; Sun, 29 Nov 2015 13:47:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=AwR+qSzo7b2neqdG8R04Bmja+hcHQRVK28vZO/mG11M=; b=tpsFY0Q/v5ZEpTBYVExKBn9lg1zZKucJfSMVGXlknCXJ/ZRj/JzRYXzWVsn8bHxXgJ /ify5Ss1fsnRZQ2tPlQh4AlmdbVHS7RXGsSxcUss7l8HZ9pobmEzYHz2Vo0zWe1Cxd3A cmChjVpqYR6nC281prs68vNkD9ocyd8D6Bm3JdkaBFJrE2TF8UPga1X/P8H4VeIZZA4+ wbKtb8QCAnSJOz08SNqpgOFm08VLrzLO7uzEWW6ZGv79fbqjqozQoefprDrhaP6+k/dj dTKwY6vdY0lXvth+TL46jVEZpyEf8DF0dAAeiDDT9UC7byT/NrKOrGDZzCrtN/NwRYhj q74Q==
X-Received: by 10.55.75.212 with SMTP id y203mr67842771qka.20.1448833638417; Sun, 29 Nov 2015 13:47:18 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id t101sm13686613qge.2.2015.11.29.13.47.17 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 29 Nov 2015 13:47:17 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Sun, 29 Nov 2015 16:47:16 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <56586A2F.1070703@gmail.com> <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com>
In-Reply-To: <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201511291647.16541.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/R4I_nzSCa08jHbc3G18F4I2EL5o>
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: Sun, 29 Nov 2015 21:47:20 -0000

Maybe I'm missing something, but hasn't this issue already been sufficiently dealt with via padding?

https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2

The record type and version fields are now frozen, and the record length field is not indicative of the real length if padding is used. The only way I could see encrypting the length field as helpful would be to further obfuscate it from something that can see the record layer but not the transport layer and doesn't know the full record size, though the padding already obfuscates it somewhat. Is this really worth jumping through hoops for?


Dave