Re: [TLS] TLS 1.3 Problem?

mrex@sap.com Tue, 29 September 2020 22:44 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B173A1366 for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 15:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sap.com
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 RAEM8sp-7ZEO for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 15:44:26 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.mail.net.sap [155.56.68.170]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF23F3A1361 for <tls@ietf.org>; Tue, 29 Sep 2020 15:44:26 -0700 (PDT)
Received: from esa5.sap.c3s2.iphmx.com (esa5.sap.c3s2.iphmx.com [216.71.157.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPSA id 4C1Dw866CyzyRs; Wed, 30 Sep 2020 00:44:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sap.com; i=@sap.com; q=dns/txt; s=it-20200722; t=1601419465; x=1632955465; h=subject:in-reply-to:references:to:date:cc:reply-to: mime-version:content-transfer-encoding:message-id:from; bh=BTFNPSHuMhqNCeU3lH4lsU8He3kXEbjyZ/RGgrZmdlg=; b=m7Bd4oAoHbTXhwVC8Y7skbGJyvv/yhDkJsjL4VjzvQJ+14g0P3EfMvPS /pp9YOfHvCw2eepND5/Z1bxTnkdKDoY/cAj/6OKXRnFZB9kxGmigHiL2Z NRIjbhPv6J/DG48uWj2nQ/rkFSirB6IpobYCaiJtbYBzZBbiOKSz42Zla 4RzXRlwQT2J3rBBqfN3T0vcq2WqCboqr0dlarzwyPXPcNsmQHN+HEuVNj 2UDH/A/Y4zI7NQnFbveeSWf4KEffXRMNp4v28clA6t2/RijUZnJL0aFdq RmKh9U9SsZ5GMMHVkWHeSFhdiF+lg6hg/ztdn1rJYaRDhJ1377U5rd5eM A==;
IronPort-SDR: befZfHVmsRJJIKqyhuW2cFkYhYS+JwKV7j1Pgt8o4HpRxwRt53WXYruBrCQZLsIkRVlbzBASYo 24GLdnvQXgI46VRoc+LESMnER8drCQYZfoXuThGQRwPQrsYdWZT0njSJwBtCsNx8njSb7sb602 EuI7kqALx1F4Mwk3QihJLLuEDVylg95o9ziXf1RoqVjdiUjWCt00XRsvPvEwPKon67K8KwmCl9 cfi6Ijfr4TfIIiu1E+KdC5osSkv+k8hefLanGifV2oq+muhWwnIPnVS2mRcLliAAyd9ZCORp2q 5ps853J+bSqlenGeSHKcakjs
X-Amp-Result: SKIPPED(no attachment in message)
Received: from smtpde01.mail.net.sap (HELO smtpde01.smtp.sap-ag.de) ([155.56.68.170]) by esa5.sap.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2020 00:44:25 +0200
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4C1Dw81RrxzyRs; Wed, 30 Sep 2020 00:44:24 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail08.wdf.sap.corp (Postfix) with ESMTPS id 4C1Dw80BD8z2xL7; Wed, 30 Sep 2020 00:44:24 +0200 (CEST)
X-purgate-ID: 152705::1601419464-0000315B-79720CB8/0/0
X-purgate-size: 1823
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E5E05404C; Wed, 30 Sep 2020 00:44:23 +0200 (CEST)
In-Reply-To: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.com>
References: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.com>
To: Michael D'Errico <mike-list@pobox.com>
Date: Wed, 30 Sep 2020 00:44:23 +0200
CC: tls@ietf.org
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20200929224423.E5E05404C@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_xcVQo4ChbZzHRIL1zUpZvnIHO4>
Subject: Re: [TLS] TLS 1.3 Problem?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 29 Sep 2020 22:44:28 -0000

Michael D'Errico <mike-list@pobox.com> wrote:
> 
> Since RFC 8446 obsoletes RFC 5246, this is a serious problem.
> 
> How is this supposed to work?   Sorry but I did not follow the
> development of TLS 1.3.  I felt that I was unwelcome in this
> group by some of the "angry cryptographers" as I call them.

The "Obsoletes" Markers used in TLS documents (rfc4346, rfc5246, rfc8446)
are pure crypto-political bullshit, they are completely non-sensical
with respect to the Editorial meaning of "Obsolete:" in the RFC
document series, as it was explained in rfc2223:

   Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.

IPv6 specification(s) can not possibly obsolete IPv4 specifiation(s)
HTTP/2 spec does not obsolete HTTP/1.1 spec (and does not try to)

Example for *correct* obsoletion:

If you want to implement the Simple Mail Transfer Protocol (SMTP),
it will be sufficient that you only ever read and refer to rfc5321
and _never_ look at rfc2821 nor rfc821 at all -- and still can
expect to your implementation of rfc5321 to interop fine with
older implementations there were created based on rfc821 or rfc2821.


The same is impossible for TLSv1.1 (rfc4346), TLSv1.2 (rfc5246)
and TLSv1.3 (rfc8446). An implementor reading only rfc8446 will
be completely unable to interop with TLSv1.0, TLSv1.1 and TLSv1.2
implementations -- and I am not even sure whether TLSv1.3 can
be implemented with rfc8446 alone and never looking at rfc5246.


-Martin