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

Hubert Kario <hkario@redhat.com> Mon, 21 September 2015 20:43 UTC

Return-Path: <hkario@redhat.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 4689A1A6FA0 for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 13:43:36 -0700 (PDT)
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_HELO_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 Q6y_lDFF2H0X for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 13:43:35 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4B51A6F65 for <tls@ietf.org>; Mon, 21 Sep 2015 13:43:34 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A232BC0B2B62; Mon, 21 Sep 2015 20:43:34 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-112-26.ams2.redhat.com [10.36.112.26]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8LKhTFw009983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2015 16:43:33 -0400
From: Hubert Kario <hkario@redhat.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Mon, 21 Sep 2015 22:43:20 +0200
Message-ID: <37975416.25dCCaMG5S@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.1.6-201.fc22.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <201509211504.18135.davemgarrett@gmail.com>
References: <20150921023216.17159.38513.idtracker@ietfa.amsl.com> <3946674.BM8ZEerjNL@pintsize.usersys.redhat.com> <201509211504.18135.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2117745.AbA3baF8mm"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JeJvdqI_yZXo4wOTotLSPubx9kw>
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 20:43:36 -0000

On Monday 21 September 2015 15:04:17 Dave Garrett wrote:
> 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. :/

true, that being said, I can see 64KiB total being limiting for 
different stuff in the future

and while sending 2MiB packets as "just a hello" is unlikely, I can see 
us sending 64KiB or 128KiB packets...

maybe we should reintroduce the forwards compatibility clause for client 
hello? it won't help us now, but when TLS1.2 gets broken then we'll be 
able to move forward with higher sizes for extensions (whatever that 
happens)

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic