[Uta] rfc7525bis section 3.2 on strict TLS

John Levine <johnl@taugh.com> Wed, 03 June 2020 20:20 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569393A0F29 for <uta@ietfa.amsl.com>; Wed, 3 Jun 2020 13:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=d0TyHsRp; dkim=pass (1536-bit key) header.d=taugh.com header.b=jc+nETsj
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 62I5x4WUQyIr for <uta@ietfa.amsl.com>; Wed, 3 Jun 2020 13:20:07 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C8F3A0F26 for <uta@ietf.org>; Wed, 3 Jun 2020 13:20:07 -0700 (PDT)
Received: (qmail 52264 invoked from network); 3 Jun 2020 20:20:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=cc24.5ed805f5.k2006; bh=+Z7aREqSwfN5AGzuS3HGREM3lGKkUgIBHFxI16/FEpA=; b=d0TyHsRpQR5Ibsow2n06rE5xYX8LC1iw16lzyTEqC/4kFBAtlU9nO28t2WAIW2Q+sHkdl40ZPldWknJSscW0GHGetYsKCIaZv820Ke8+pKAQMhGPNMP7VYVTtWFKuRJS29QSqkRxNIrDY0jStuk7GHh3UPww3G1tNBk8pMDD5vLpGJCH8kBP3W9axX9dUG4XXzP868bf+kbcaWrdq7/sLC3/EEWUexbZf6OwT6jyF5cmN6iLirO3KuMPDlCl5OPA
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=cc24.5ed805f5.k2006; bh=+Z7aREqSwfN5AGzuS3HGREM3lGKkUgIBHFxI16/FEpA=; b=jc+nETsj+KNJFC9QSRwjzKt1z+tNc9KiY3tmEEV2i2bd/FjMJVrZz6dJ61zKXXJsA1is0sSiTAA7a+/GnURc3eBjoVwrz40fvewR1MhAHq57SLNs63VwNbFHf/SVfspWXu+ZVQL5tG/ZtCCDj8xO3E1PrXArIYvnP0l400LRotjoLlgHupZHYdDMdy9xEc9I/wYZLM6IER1+7Pem+t+192AWwfrXlrqMdlAKsBOUWagg/3P60hHE/tAYIr/nsFkX
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Jun 2020 20:20:05 -0000
Received: by ary.qy (Postfix, from userid 501) id 720421A1D074; Wed, 3 Jun 2020 16:20:05 -0400 (EDT)
Date: Wed, 03 Jun 2020 16:20:05 -0400
Message-Id: <20200603202005.720421A1D074@ary.qy>
From: John Levine <johnl@taugh.com>
To: uta@ietf.org
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/uUsiYqTDWa-52QZDXojXsOC1LXc>
Subject: [Uta] rfc7525bis section 3.2 on strict TLS
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 20:20:09 -0000

Section 3.2 says in part:

   o  In cases where an application protocol allows implementations or
      deployments a choice between strict TLS configuration and dynamic
      upgrade from unencrypted to TLS-protected traffic (such as
      STARTTLS), clients and servers SHOULD prefer strict TLS
      configuration.

In the STARTTLS services I know, submission, POP, and IMAP, this
doesn't match the way clients work. They're normally configured to use
TLS but fall back if it's not available, and they all know if the
strict TLS service on port 993 or 995 isn't available, to try port 143
or 110 instead. Presumably any middlebox sophisticated enough to strip
STARTTLS can also block the other ports.

I would say instead that they SHOULD use TLS on either port, remember
that it worked (which they all do), and complain if it later stops
working.

You should also mention MTA-STS (RFC 8461) which is the mail
equivalent of HSTS and is widely supported at least among large mail
providers. I'd also think a stronger reference to TLSA would be useful
since clients should fail if they have a TLSA record and there's no
TLS certificate to match.

R's,
John