Re: [TLS] Version (in)tolerance

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 17 June 2010 12:27 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330813A68AB for <tls@core3.amsl.com>; Thu, 17 Jun 2010 05:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV0FCLFV+jXt for <tls@core3.amsl.com>; Thu, 17 Jun 2010 05:27:27 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B3CAB3A681D for <tls@ietf.org>; Thu, 17 Jun 2010 05:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276777652; x=1308313652; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20marsh@extendedsubset.com,=20pgut001@cs.auckland.ac .nz|Subject:=20Re:=20[TLS]=20Version=20(in)tolerance|Cc: =20brian@briansmith.org,=20tls@ietf.org|In-Reply-To:=20<4 C1A0D75.1050309@extendedsubset.com>|Message-Id:=20<E1OPEB H-0005cn-UP@wintermute02.cs.auckland.ac.nz>|Date:=20Fri, =2018=20Jun=202010=2000:26:51=20+1200; bh=+FszotMw3NcPLLJqTvjegMd9UWGRhY+vWqcFqNqBRLg=; b=oT5WP6jdVanB8ZOYzCaQTIQagg1/lP+AqLIkSbaRvOuKVt0E4EWjyxkW 4b0RzpJeR2DdJT1tT2y4whKSZpQw9UZPe6x0AmqtEeIkuh2RdcOAztyHC HFz+d9tS7Eiaa9xS/MiGsw3IHCLwJ+S9MjFMoFxkiH9GRqLTnF3b+6uCi U=;
X-IronPort-AV: E=Sophos;i="4.53,431,1272801600"; d="scan'208";a="11571317"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing
Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Jun 2010 00:26:52 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1OPEBH-0005cn-UP; Fri, 18 Jun 2010 00:26:51 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: marsh@extendedsubset.com, pgut001@cs.auckland.ac.nz
In-Reply-To: <4C1A0D75.1050309@extendedsubset.com>
Message-Id: <E1OPEBH-0005cn-UP@wintermute02.cs.auckland.ac.nz>
Date: Fri, 18 Jun 2010 00:26:51 +1200
Cc: tls@ietf.org
Subject: Re: [TLS] Version (in)tolerance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 17 Jun 2010 12:27:28 -0000

Marsh Ray <marsh@extendedsubset.com> writes:

>* If an optional protocol feature has no implementations that are available
>and widely used for testing, it can be relied on not to work.

And that's exactly why I reject major versions other than 3, I have no idea
what version 4 will be or require, and I also have no way of checking that I'm
not subject to some sort of rollback attack or who knows what if I include
handling for a 4.x version.  So in order to force users to get a version that
deals with whatever security catastrophe 4.x is meant to address, I want to
make sure that they're forced to upgrade.

This was a problem with PGP 2.x, there was never any strong reason for people
to upgrade, and it took forever to get people to move off it (some are still
using it).  Someone (from memory it was Jon Callas) has complained that PGP
2.x needed some fatal flaw found in it to force people to finally move to
OpenPGP.  So having a fall-over-and-die trigger can be a good thing, not a
flaw.

In any case though since no-one has any idea what 4.x will be, or why we'd
need to move to it, or whether it will ever appear, this is all just
speculation, it's like arguing over what clothes work best for interstellar
travel.

Peter.