Re: [TLS] Thoughts on Version Intolerance

Dave Garrett <> Thu, 21 July 2016 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 943B212D7A4 for <>; Thu, 21 Jul 2016 13:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.374
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ta_vM2TJemp6 for <>; Thu, 21 Jul 2016 13:04:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A838912D83C for <>; Thu, 21 Jul 2016 13:04:28 -0700 (PDT)
Received: by with SMTP id 52so50413584qtq.3 for <>; Thu, 21 Jul 2016 13:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id z32mr109487qtc.69.1469131467827; Thu, 21 Jul 2016 13:04:27 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id p94sm5238003qkp.44.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Jul 2016 13:04:27 -0700 (PDT)
From: Dave Garrett <>
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: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Thoughts on Version Intolerance
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.