IETF Logo Mail Archive

Re: [TLS] Thoughts on Version Intolerance

Dave Garrett <davemgarrett@gmail.com> Thu, 21 July 2016 20:04 UTC

Return-Path: <davemgarrett@gmail.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 943B212D7A4 for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 13:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level:
X-Spam-Status: No, score=-1.374 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=1.326] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ta_vM2TJemp6 for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 13:04:34 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 A838912D83C for <tls@ietf.org>; Thu, 21 Jul 2016 13:04:28 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id 52so50413584qtq.3 for <tls@ietf.org>; Thu, 21 Jul 2016 13:04:28 -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-transfer-encoding:message-id; bh=e3uzpYIhh1TQPJEgc9veTyYl0Y8JuLqwDZ+29Ec/wdo=; b=XIjnMNc2QZLk8TK14pE5ORz1IdjuO20HrSZtqoGH97KU7egiUf8wR6Y8ANV67X17dV /LPa3e5mF/ZTwd4V+08nvv4r6S+v9ZZkh6IapVXp6+7JiXj0Vk3sp3E9gqisjnskVLuW +1kVsvV2WjjxPPEjF4Vr6yxc50QURDH31ZRTLcCbw6a05oxCFrOE2WH0cJ9IjAQFs7dL IERBGDZdpQ+COfbTpDEM3sqwwA2I5jH0GxDbmxOqmWqYXSZjXebh8LTOwTYO+HVHFS2K PLh4zG4yYpz/4hxdsZNzCAgOdJvvK0pMIYCS+9loRf0RMnnD+/v1fj+aMI3iZ2hYkSq8 xoqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=e3uzpYIhh1TQPJEgc9veTyYl0Y8JuLqwDZ+29Ec/wdo=; b=SsQVIH/80KYOorgzKs0m0DDL6atAC26ts3Mgf8V+DXqlonpqB1VYHsSAlW3N4vJA1d ACudJ6y8hP/jeLFkd3QMZHJjjMOR3cJ2Kfdim87VlRnLbT770lHRrm0M97EVXnxQ9l73 pvTRjrTbFOe/5p2AnhXw46hlwpUDAGkPAqoMTyJzK+WyyAx6JRCquV72b+8FuYlV4aix B+SGPuQunR0/9QGvZG1k27gh24v/SbWsCeBFjtmxfgCwPTdsMN+YVjKKcnB7GtT5n/WK FpgBxyUbYIbrI0dPvYjmbjUDERH4NoQFvjmJMbSWOSmJhoge7VurXXL/VzafrgIYyOvI uxJw==
X-Gm-Message-State: AEkooutIS34ixkAQjBFNsOFzM2INhkIgPZIC0pfNG54c2W7l255dGAo/8qvu4OQMb/+Shw==
X-Received: by 10.237.38.35 with SMTP id z32mr109487qtc.69.1469131467827; Thu, 21 Jul 2016 13:04:27 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id p94sm5238003qkp.44.2016.07.21.13.04.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Jul 2016 13:04:27 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Thu, 21 Jul 2016 16:04:25 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com>
In-Reply-To: <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201607211604.25745.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sF9LjZVO7hWktwJ8VJ28yiOE71w>
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: Thu, 21 Jul 2016 20:04:35 -0000

On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote:
> On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> > Any ClientHello with > 200 Cipher suite code points indicates fairly insane
> > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.
> 
> and which part of the standard says that it is "_perfectly_sane_" server 
> behaviour?

On this specific type of issue, I agree with Martin here that sanity checks for over-the-top configurations are reasonable, however we should be standardizing this, not having every implementation do this ad hoc. We really should go through a list of these sort of implementation break points and start picking arbitrary lines to add to the spec. They don't have to be ideal numbers; just something better than an upper limit of 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for this example. Yes, certain fields have to stay open-ended, namely extensions, but reasonable limits should be added where appropriate.


Dave

v2.23.0 | Report a Bug | By Email