[TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)

Dave Garrett <davemgarrett@gmail.com> Thu, 21 May 2015 16:10 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 625531A8885 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 09:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 XXVdUdKbyaJc for <tls@ietfa.amsl.com>; Thu, 21 May 2015 09:10:45 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 922E01A8874 for <tls@ietf.org>; Thu, 21 May 2015 09:10:45 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so58751882qkg.1 for <tls@ietf.org>; Thu, 21 May 2015 09:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:user-agent:mime-version:to:content-type :content-transfer-encoding:message-id; bh=hjXyn4oVup7iH5iFXu0N6mz1LTtG3sBUPZ+zsOp1wzs=; b=xHZJB91w6PQgIF0v/Fv+RNwbPQvJ0fVv9yp8Mlwk8L/PvD1Mq21jGd0uZl1jt5sdxT LMh4NUjDWdoU+UjueudcoRvzlxjsIZdb+lRa8zp2Zr2232EUlECsz0qiU2flAWPLYM2A vETWxpunYsgBwB1hwAFX3cfkxLnMKF+0AcxWFTO7EeCleBsG88muxp8HHBWS0USGFrGs EN3ggREka94NSv8CQL4xT+W/sRpni5hSWNt02+E87Yf4/QjsLNOuuiqdnC1QuTObaIzO GY/mRc25gaIF0QvoEEH5pNj2JF9xeXOCvzGvo6FCe8TlCRlLyMfa4LAQ1MVD1mX+/uF/ iKOQ==
X-Received: by 10.55.25.134 with SMTP id 6mr7957814qkz.13.1432224644796; Thu, 21 May 2015 09:10:44 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id u95sm13524516qge.16.2015.05.21.09.10.43 for <tls@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 09:10:43 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
Date: Thu, 21 May 2015 12:10:42 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201505211210.43060.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Hc9whYbvkQ_MJp620nC3WzBxEqI>
Subject: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)
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: <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, 21 May 2015 16:10:47 -0000

I was going to hold off on suggesting this due to other topics dominating the list, but we might be in a kill-the-old-junk mood due to the latest old-junk vulnerability, so...

Old versions of TLS need to be phased out at some point (even the one we're designing now), however the current modus operandi is generally to wait until a catastrophic breakage forces everyone into a panic disable. I'd like to at least try to do better prior to the next time. I'd like to propose giving servers & clients different expectations as a transitional measure:

1) No general change to current TLS other than pointing to the UTA BCP from time to time.
https://tools.ietf.org/html/rfc7525

2) For TLS 1.3, add a blurb to the effect of:
"Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason.
Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

The reasoning here is that major server updates are unfortunately uncommon, but client updates are routine. Server implementations get updated, but deployments don't/can't keep up. There are no legitimate clients that do not support TLS 1.2, and even plenty of old ones can support it if actually enabled (and those vendors should get their act together and push updates to flip that on for all old versions, regardless of EOL status). The current strategy is basically to support everything forever and that has been shown to be quite detrimental, especially over the past year.

Note that this is not just about dropping support for versions X & Y. It's about giving implementations a chance to drop all the baggage that comes with those old versions and focus only on reasonably modern standards instead.

For those that would disagree with mandating servers drop support for the protocol from 1999, I think it's reasonable to just require you to have to ignore the RFCs if you really want to keep doing this sort of thing in 2015. Everyone else should have servers that have at least vaguely reasonable minimum standards out-of-the-box. Allowing obsolete security to be considered legitimate is a public hazard, and I don't want to wait around for more exploits to deal with it. Security is only as strong as the weakest link; we need to start baking this into new specifications


Dave


PS
I am aware some vendors irresponsibly abandoned lots of mobile users on obsolete OS versions. They should be treated like WinXP+IE6: useless until you download a better browser yourself. If that's not possible, complain to the hardware vendor that didn't provide updates.