Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

Dave Garrett <davemgarrett@gmail.com> Mon, 21 September 2015 19:04 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 830161B3438 for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 12:04:22 -0700 (PDT)
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 0vERHGhmGXki for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 12:04:21 -0700 (PDT)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 CA1551B343A for <tls@ietf.org>; Mon, 21 Sep 2015 12:04:20 -0700 (PDT)
Received: by ykdz138 with SMTP id z138so31519192ykd.2 for <tls@ietf.org>; Mon, 21 Sep 2015 12:04:20 -0700 (PDT)
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=ztKgMom37vjQUvjj5YWZWxxvD+MNch35gklQKO2fYe0=; b=yXxQ4odOVklp/ASOfUonwo51wnn5qNKrPtX3fvDluJoYSC1cQMRSwApjSCJ/oVt6Bd 9cAwQejWX8ZshY2stGYeYpffl1oDQ0BoOJjhyOySqf/ZbTQmQ7GOzHCmAtwzAguzZmHe P9cjaViX8Fg1SA2m8GpP+Ytxt4NRjkXlj4QpkI/o2JxC4j8v/43ZhDDqJDRt9Q2Ui+lR Ty5U//5zLBmYlaKtHO4pgFGPfppauUEFF5GwSl6W/gXOVs72kbviyhfMPxA2MCTiI8cE d2g603QaZYVJ31NE1U9bDdLBZKJU+GSTzdDycc6cqLfEx59ztIQCko0WsT82C6xwKfc7 KY6g==
X-Received: by 10.13.210.5 with SMTP id u5mr18647965ywd.154.1442862260036; Mon, 21 Sep 2015 12:04:20 -0700 (PDT)
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 t83sm9862489ywa.46.2015.09.21.12.04.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Sep 2015 12:04:19 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Hubert Kario <hkario@redhat.com>, William Whyte <wwhyte@securityinnovation.com>
Date: Mon, 21 Sep 2015 15:04:17 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20150921023216.17159.38513.idtracker@ietfa.amsl.com> <201509210020.21640.davemgarrett@gmail.com> <3946674.BM8ZEerjNL@pintsize.usersys.redhat.com>
In-Reply-To: <3946674.BM8ZEerjNL@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201509211504.18135.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/IPWulXE_VGJylXB2FBlm8gaucxs>
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
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, 21 Sep 2015 19:04:22 -0000

On Monday, September 21, 2015 07:22:03 am Hubert Kario wrote:
> On Monday 21 September 2015 00:20:21 Dave Garrett wrote:
> > A strong reason is it not being possible to change due to the need for
> > TLS 1.3 clients to be able to connect to TLS 1.2 servers that won't
> > understand a format change. Even if it were technically possible, I
> > wouldn't expect all implementations to safely handle it.
> 
> the TLS1.2 standard says that the ClientHello MUST match either 
> extension-less or an extension-present format and server MUST check that 
> the overall length of message matches the processed data, so we can't 
> have extensions-after-extensions (which theoretically could have 3 byte 
> length field).

Yeah, adding a second extensions vector in addition to the existing one was my other thought, but it's too messy for me to think it'd be worth trying. Looks like that's not even possible. I think we're stuck with the current TLS extension size limits forever.

I doubt anyone would really want to use any keys in the megabyte range anyway. Post-quantum crypto research/experimentation for TLS & other network protocols should really focus on systems with smaller keys. Even if a giant-key scheme was ideal, you'll have a very hard time convincing people to actually use it, no matter how much they might need it. :/


Dave