Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <hkario@redhat.com> Sat, 23 July 2016 21:52 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF60F12D597 for <tls@ietfa.amsl.com>; Sat, 23 Jul 2016 14:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level:
X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 t3G5VeRkB8C3 for <tls@ietfa.amsl.com>; Sat, 23 Jul 2016 14:52:42 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6A112D50C for <tls@ietf.org>; Sat, 23 Jul 2016 14:52:41 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u6NLqdrn009628; Sat, 23 Jul 2016 17:52:39 -0400
Date: Sat, 23 Jul 2016 17:52:38 -0400 (EDT)
From: Hubert Kario <hkario@redhat.com>
To: Brian Smith <brian@briansmith.org>
Message-ID: <1347298854.18580677.1469310758848.JavaMail.zimbra@redhat.com>
In-Reply-To: <CAFewVt760KsO6oX5u-ZQJmKB-M5FcTb7mUTz4Z4FaT2QopwCxw@mail.gmail.com>
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> <CAFewVt760KsO6oX5u-ZQJmKB-M5FcTb7mUTz4Z4FaT2QopwCxw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [94.112.188.164, 10.5.101.182]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF47 (Linux)/8.0.6_GA_5922)
Thread-Topic: Thoughts on Version Intolerance
Thread-Index: Xlx6qYJ38SwYGOsikFiTZa5LUIoHXw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8fitSMDRgn7WeM6Nit5VHV80Gcw>
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] Thoughts on Version Intolerance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 23 Jul 2016 21:52:45 -0000


----- Original Message -----
> From: "Brian Smith" <brian@briansmith.org>;
> To: "Hubert Kario" <hkario@redhat.com>;
> Cc: "Dave Garrett" <davemgarrett@gmail.com>;, "<tls@ietf.org>"; <tls@ietf.org>;
> Sent: Saturday, July 23, 2016 3:37:24 AM
> Subject: Re: [TLS] Thoughts on Version Intolerance
> 
> Hubert Kario <hkario@redhat.com>; wrote:
> > I'm quite sure that if I were sending a huge extension or many big
> > extensions,
> > the percentage of servers that are incompatible to them would be similar,
> > if
> > not worse. A relatively small 3KiB client hello already causes issues and
> > this
> > is not exactly something impossible to achieve with just TLSv1.2 and
> > session
> > tickets.
> 
> Don't expect a server to accept a ClientHello with a session ticket it
> didn't produce. In particular, a server could very reasonably reject a
> session ticket larger than the ones it produces, and it might produce
> only very small ones.

oh, I agree, I don't plan to use session_ticket for testing client hello size

> More generally, when assessing compatibility, generally it is better
> to consider only initial handshakes, using the data one would normally
> send in an initial handshake. And, if you are considering 0-RTT key
> shares, then it would be better to measure the case where only ECC key
> shares are used separately from the case where non-ECC (old-school DH)
> key shares are used.


what I wanted to say, is that those limits are most likely hardcoded in
the libraries (OpenSSL's certainly were), so they may well be ticking time
bombs for the time when some user deploys such broken implementation with
client certificates and for one reason or other connecting clients have
very big certificates.

Then you can hit those limits even if using TLSv1.2 protocol.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic