IETF Logo Mail Archive

Re: [TLS] ban more old crap

Dave Garrett <davemgarrett@gmail.com> Fri, 24 July 2015 18:04 UTC

Return-Path: <davemgarrett@gmail.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 ABCCF1A89F1 for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 11:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 Rebjyz-Ojes1 for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 11:04:11 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 3F4B11ACDEB for <tls@ietf.org>; Fri, 24 Jul 2015 11:03:16 -0700 (PDT)
Received: by qkfc129 with SMTP id c129so19095443qkf.1 for <tls@ietf.org>; Fri, 24 Jul 2015 11:03:15 -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-type:content-transfer-encoding:message-id; bh=ZbC41UBeKFWD7umGsHMT49vJ4eVsjD1VuiIvACvrX0o=; b=OYRjPDzGz359J3hUS4Y5HnmC9jFEsqXE7Mt1jc9v62RsCkJ/9u0AWHPs7iruG89Rim lQDP+zZXHVq1V4tSWrmSvujydvoZjFZOrg6V+u3J3iIDof296ZmXJhx+Mb0+njY9KwcL /5LQdLH66dR4JkvjZMydF+8rejqAzGEyzIzoR0ETwWo5t2X7Nm3GrMcGHJl6Hp2QxQQV ESTsshoDZVgT/F5yZhmZ0BUbp2P9JBbSW92Ak+2tSQmmwqqhUUNL6aBUPSkP/bFURoFr /2DhS1Uqpc3kPG6Mu7T2OOejVW9B1qWDoHWp3K7hI4sSPyUYUZbCYgBc1UA6M4DWIzKB TjmA==
X-Received: by 10.55.40.65 with SMTP id o62mr21467071qkh.41.1437760995458; Fri, 24 Jul 2015 11:03:15 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id o64sm4421694qkh.25.2015.07.24.11.03.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 24 Jul 2015 11:03:14 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Hubert Kario <hkario@redhat.com>
Date: Fri, 24 Jul 2015 14:03:13 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201507221610.27729.davemgarrett@gmail.com> <201507241257.43115.davemgarrett@gmail.com> <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com>
In-Reply-To: <2164745.i4WjRk8WKj@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201507241403.14071.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/geFTszahlojfPtVfqDhyEmx1n9s>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ban more old crap
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: Fri, 24 Jul 2015 18:04:12 -0000

On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote:
> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> > To be clear, the wording I have in the PR is not this broad. It only
> > requires aborting if export ciphers were offered by a TLS 1.3+ client, not
> > just any client.
> 
> and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to-
> TLS1.3?

TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 only. A TLS 1.0-1.2 client, or at least one offering that, is what it would not complain about.

For the rare case of "legitimate" use of export ciphers, namely spiders, it'll need a fallback attempt with a full set of suites. Export ciphers are not something we should be accounting for allowance of in any protocol we want to claim to be secure.

We do have to remember that even _offering_ them is dangerous, even if they're not negotiated. It's dangerous to even _support_ them, even if not offering. Having this in any way presents an unacceptable attack surface for a MitM to try and find a way to confuse implementations into using them. If all implementations were perfect, yeah, this wouldn't be a problem. History has shown this is not the case. :(


Dave

v2.23.0 | Report a Bug | By Email