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

Dave Garrett <davemgarrett@gmail.com> Thu, 21 May 2015 23:20 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 A579B1A90CE for <tls@ietfa.amsl.com>; Thu, 21 May 2015 16:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.135
X-Spam-Level:
X-Spam-Status: No, score=-0.135 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, FRT_LOLITA1=1.865, SPF_PASS=-0.001] 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 YOWgGD4mhhKq for <tls@ietfa.amsl.com>; Thu, 21 May 2015 16:20:24 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 806BF1A8931 for <tls@ietf.org>; Thu, 21 May 2015 16:20:24 -0700 (PDT)
Received: by qkgv12 with SMTP id v12so1622187qkg.0 for <tls@ietf.org>; Thu, 21 May 2015 16:20:23 -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=NbYZ5HPjgHjq7li3K9Rh0tAltNt/za1g1Xagv0L/LTE=; b=papf91lqp+Mon6Q1F+Gcx2/A9gNKSkcsAI9zYRu+j6RfiQI3ipXGP9U/HMwwXo1nRu liqYx1SS3Wot/7KIu//VCgzEvERkpiXFWG5eNhUnHFB0b3QR3Uw9uoGuq5Ghbp/xetdJ /NII93CCIJ6WtaF2td9IP5VG51X/NHh55N0tsQr0T+patISccXzGN+TnO3W5M/1+ktFz bsGdMHxH/Rx/17BHCIJehFR++l8CD0QY4vIskCX9msCd0aVA1sBe+oTIWldJdnvN/C2k ahYKX5plyfQNBtI/pgT745rm90hlEMKJ+vPoKPM3dlcUnXVzpaQ7tyJv7bTvb2/qpfLt u6PA==
X-Received: by 10.55.18.155 with SMTP id 27mr11148265qks.36.1432250423858; Thu, 21 May 2015 16:20:23 -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 18sm212165qgh.40.2015.05.21.16.20.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 16:20:23 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Thu, 21 May 2015 19:20:21 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201505211210.43060.davemgarrett@gmail.com> <CACsn0ck84SMT+Eqgdz7SBFQmaP0tFZQpX03Q0WyJtTgh5MhpkQ@mail.gmail.com> <943DD5B5-DD98-4AB5-80AF-EB56D2EABC86@gmail.com>
In-Reply-To: <943DD5B5-DD98-4AB5-80AF-EB56D2EABC86@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201505211920.22236.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ahDYLVui0N1LUuTZ1PNE8Eag9C8>
Cc: "maray@microsoft.com" <maray@microsoft.com>, "tls@ietf.org" <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 23:20:25 -0000

On Thursday, May 21, 2015 06:59:17 pm Yoav Nir wrote:
> Server implementers will ignore this even if we make it a MUST.

So be it. As said before, there are no IETF police. Responsible server implementations will follow the spec and the ones who want to trade security for compatibility will not. Certainly not ideal, but it'd be a big improvement over everyone ignoring things until they explode. At bare minimum, when the inevitable new vuln is published, the organizations running compliant implementations will be able to show they took things seriously and everyone else did not. I'd at least like to write down the fact that everyone should be aware that it should be obvious that continuing to use an obsolete security protocol for over a decade and a half is not wise. It would help upgrade security more than ignoring the issue.

On Thursday, May 21, 2015 07:09:42 pm Yoav Nir wrote:
> Then point at the BCP. Only problem is that it doesn’t say what you want it to say (it allows TLS 1.0 when the client does not support anything else)

In my first post I said that I don't propose changing anything for existing deployments. The BCP is currently a "SHOULD NOT" for current TLS. I'm proposing a "MUST NOT" for TLS 1.3+ implementations only.

The BCP is also not directly part of the TLS spec. What I'm suggesting is considering 1.0/1.1 to be not legitimate forever, not just not "best".


Dave