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

Thijs van Dijk <schnabbel@inurbanus.nl> Thu, 21 May 2015 19:07 UTC

Return-Path: <schnabbel@inurbanus.nl>
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 78B661A8896 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 12:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.988
X-Spam-Level: *
X-Spam-Status: No, score=1.988 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no
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 B9ApqT6YChAV for <tls@ietfa.amsl.com>; Thu, 21 May 2015 12:07:27 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 EC4E91A88C7 for <tls@ietf.org>; Thu, 21 May 2015 12:07:24 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so25168740wic.0 for <tls@ietf.org>; Thu, 21 May 2015 12:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZSytv7mmOBckRgDswMhfOdu4AFNvvqT142NjUxtNGsw=; b=G3Lr43xGSoECsxkEy7NCZ8oyBBdtQ/KX3IF37cgc/oqu0M0VCVJUj4+OzUC7A5xMg1 L2LV96e3Oqtkk5ffb7Je8vWnzfISQxYPrOCfMEzPiGKgaajvzkXzQxmfAhk0uT0m1oSp 6ylfbEpk7G9TyIvkt6ftwvUJsA00fRoKUM4QY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZSytv7mmOBckRgDswMhfOdu4AFNvvqT142NjUxtNGsw=; b=d+i0XSDrcfvgeFLKxhIDwd5qxf9dioM8YfSRfQ6NRAI+p+Gzsjt0Xl9RSg/WrWzIA+ cblt5msfP0/M7wLQK6mvRfAPoToBrTFecz6abmFhQYbulsr6iHWOx2v7TlLgQq3Shcja cZvYUfNmUfjAY8rPBEOXAA/A6y2m9edYekfUCyUb+o1N/mC+Pe9vNoe/HKRBX8nsiYB3 mHUchZL8qH4idU88Qitaxdu8cnd9OYXUcORR+5K8WFVzz8EEo4/0x5+HCyLJcgVglVoW nX031K9wGUpbWcfx7CkkDwQENH6g8KuUtQYm2djUT4mH1QyB+gF2j/aeMsYUEosVK/lt jsTw==
X-Gm-Message-State: ALoCoQnsoFuYd1jNvo5HNPZIs2hVBR/qDhcXj7SNxkgAjDfMwy82dKY7F7zueQOV/KhD4E4BkoiH
MIME-Version: 1.0
X-Received: by 10.180.95.10 with SMTP id dg10mr314187wib.41.1432235243481; Thu, 21 May 2015 12:07:23 -0700 (PDT)
Received: by 10.28.214.206 with HTTP; Thu, 21 May 2015 12:07:23 -0700 (PDT)
In-Reply-To: <201505211210.43060.davemgarrett@gmail.com>
References: <201505211210.43060.davemgarrett@gmail.com>
Date: Thu, 21 May 2015 21:07:23 +0200
Message-ID: <CADGaDpEjG8RfKzwnKjtYun_TTo9ipctQwx9DsDOWfSkory65rg@mail.gmail.com>
From: Thijs van Dijk <schnabbel@inurbanus.nl>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04447f83ec3f5d05169c4010
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vjP19rnaWexAc5_s4eCI62dg9JM>
Cc: tls@ietf.org
Subject: Re: [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 19:07:29 -0000

On 21 May 2015 at 18:10, Dave Garrett wrote:

> 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."


In an ideal world I'd be all for it, but in reality I think this would do
more harm than good in the sense that it would postpone deployment of
TLS1.3 rather than speed up the deprecation of 1.1 and 1.0.

Case in point: as of last month, 15-20% of my employer's revenue still
comes from clients using IE6-8. (Mostly law firms and government branches
who don't care so much about security as they do about liability - if at
all. And barring the n'th catastrophic breakage, TLS1.1 is not a
liability yet.)
My boss isn't going to forfeit that amount of cash simply because his IT
guy says the BCP says he should. Nor should he! If it's an exclusive choice
between either supporting 1.0 and 1.1 but not the newest 1.3, OR having 1.3
but having to make do without one-sixth of his revenue, this is a
no-brainer.

Users and site operators alike would benefit the most from a
having-your-cake-and-eating-it-too scenario, where users with a modern
browser can enjoy the newest security features, while the soft-touch
deployment will make adopting the newer version more palatable for the
managers of this world, even if it does mean the odd panicky removal every
other month.

-Thijs