Re: [TLS] RFC8446 backward compatibility question

Christian Huitema <huitema@huitema.net> Fri, 06 August 2021 00:30 UTC

Return-Path: <huitema@huitema.net>
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 B77183A1368 for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 17:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XXUTHgkmApB5 for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 17:30:14 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 000A73A135E for <tls@ietf.org>; Thu, 5 Aug 2021 17:30:13 -0700 (PDT)
Received: from xse14.mail2web.com ([66.113.196.14] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mBnkU-0013Ry-D2 for tls@ietf.org; Fri, 06 Aug 2021 02:30:10 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4Ggmb114J9z1tbC for <tls@ietf.org>; Thu, 5 Aug 2021 17:30:05 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mBnkT-0000vC-0U for tls@ietf.org; Thu, 05 Aug 2021 17:30:05 -0700
Received: (qmail 7278 invoked from network); 6 Aug 2021 00:30:04 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.233]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 6 Aug 2021 00:30:04 -0000
To: Toerless Eckert <tte@cs.fau.de>
Cc: Richard Barnes <rlb@ipv.sx>, "tls@ietf.org" <tls@ietf.org>
References: <20210805204355.GB57091@faui48e.informatik.uni-erlangen.de> <491413A8-E420-49AA-AA0D-1494C29F20C8@akamai.com> <20210805213523.GD57091@faui48e.informatik.uni-erlangen.de> <CABcZeBMENb1bvgtWG7o180NM2Pm43qkFBNe9kRv3F4A49k21tg@mail.gmail.com> <20210805225244.GE57091@faui48e.informatik.uni-erlangen.de> <CABcZeBMbfQdKi2cOFip5o4CFfGEtFKDSKJM=Zvt6=0cZWXqb4w@mail.gmail.com> <20210805231102.GF57091@faui48e.informatik.uni-erlangen.de> <CAL02cgQnJYCthmnX6j0U8dCjE1fJZX2Kf9MAE3-k06Tcgqh=2g@mail.gmail.com> <4edb7050-2e05-ebef-12c7-cde8471dc94d@huitema.net> <20210806001416.GJ57091@faui48e.informatik.uni-erlangen.de>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <40ea0fb8-5d83-ace1-175a-ac7b36810d22@huitema.net>
Date: Thu, 5 Aug 2021 17:30:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20210806001416.GJ57091@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.14
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5y+TdELUc3IPXxOn6N6uGoCj3CSdYahsEhiizd3WfZtERPM XJAs9uL1tqBJ6A4bgIPlYLLlWSy3OGfGBNeqx2anHyJxjDLo4/ugN15VVJm4KWrxEaaKeSxe0Wrx 6M4G5/Wm4Zd53xWOh54QqC5fJ2uRkPQNIL4vgWmCSFfr3DzBuVxh7hoyMoWHMkqYfQEaAmuTN39V SAGznwTrlYf+WLCVpbt3W3gfNnuKkqGP09ZKLP25Cgscc2Nqd9azmDa4ZbYxn04qRLKGrOrEzQDq o2Fe5e0H1p2YD3fIDgqE3F/hSENKwnAR2oVisY+bnEqWCKi5klmK1va3wJScg92pg//jdNpXP/ul EV6DIUDLc0Yd6iTlYE+Zcn8p1rPpG64P1y7nVrUQfxkYoV3jt7fqlPgR0kaOEXLuWd+6zLg4wp8u X1nsyWu8Q0HDoORE+fy5gr3LgKffTIgl7nuGO/IJU1342OUMeHyTpNN0eXybX/w7/4a+Zyc1sUYl ckMDbruAhxfaTSRjFdfhbaOt3LLrhebQ6tEBc/jeO8LqYflYiCA5agI8gpksXLpUEFdEVNILXwUT JUeAOIZoIpOKYzXqeUW2EnFzsC48bTEFY06/YbB87aZA2T1TDpm1DkXX6Es5zXntCB3G1CwpaI3Z 4ESkMWDVEmlGVTLa11kLY1eVj2D9MM/JJFYE5xmX/aeFzZOaGq/ZcpPgEJKLbDyaC/LdLvvYrm64 CzlVANSCbleLCj6SF/pVB9v9zY0h8asEYmbGGsLRRrpb2yB+9SGl7QVSZMRQ678StFWH4NUMqD+J xWN5th0sl4OFxBT1d23OUWLVuGpBtL9ewJnoHKUNLZpf7DfZK/JdWvgd2/FibEdMM0Jnxu/VcARR JJg0CPVGXFYA7xCx7SWZBpdAUArn/St00aGa08t44IPL25P8DLNzMDIRDLdvK/cKOEqlCIPGIfYQ DNLcNVwigJ23suxKKQl6t4RW
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JDzpcVdCVYN1t233jazdlyw3Bdw>
Subject: Re: [TLS] RFC8446 backward compatibility question
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: Fri, 06 Aug 2021 00:30:19 -0000

QUIC specifications are definitely not ambiguous. My point is that QUIC 
provides incentives to develop TLS stacks that only support 1.3 and 
later releases. Someone is going to use these stacks in other 
applications. Special purpose web servers would be one such application, 
say supporting H3 and providing a fallback to H2. So I certainly believe 
that we will find deployments of TLS over TCP that are only supporting 
TLS 1.3. Whether that's a good idea is something that the market will 
decide...

-- Christian Huitema

On 8/5/2021 5:14 PM, Toerless Eckert wrote:
> RFC9001/4.2:
>    "Clients MUST NOT offer TLS versions older than 1.3. A badly configured TLS implementation could negotiate TLS 1.2 or another older version of TLS. An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated"
>
> At least demultiplexing between HTTP TLS and QUIC TLS implementations
> should be an challenge due to encap differences. Sharing a single
> implementation maybe a bit more advanced if TLS/TCP should support
> 1.2.
>
> Cheers
>     Toerless
>
>
> On Thu, Aug 05, 2021 at 04:58:54PM -0700, Christian Huitema wrote:
>> Also, it depends whether the application is HTTP or something else. QUIC
>> makes an explicit reference to version 1.3. AFAIK, several implementations
>> of QUIC use stacks that just implement 1.3, no attempts at backward
>> compatibility whatsoever.
>>
>> -- Christian Huitema
>>
>> On 8/5/2021 4:15 PM, Richard Barnes wrote:
>>> I’m not aware of any spec (at least in the IETF) that mandates support for
>>> prior versions.  Are you?
>>>
>>> My point being that there is a pretty universal default assumption that no
>>> such requirement exists.  No different for TLS, and thus no need to explain
>>> when that’s the case.
>>>
>>> —Richard
>>>
>>> On Thu, Aug 5, 2021 at 13:12 Toerless Eckert <tte@cs.fau.de> wrote:
>>>
>>>> Sure, i like playing TLS cluedo ;-)
>>>>
>>>> But for uneducated readers, i was thinking more about text that uplevels
>>>> to the operational
>>>> aspect of interoperability:
>>>>
>>>>     All (curent) TLS versions can negotiate to lower versions, but
>>>>     no version specification mandates actual support for such a lower
>>>> version.
>>>>
>>>>     In result: to ensure interoperability with a peer of version 1.x,
>>>>     it is not sufficient to support 1.y, where y > x, but an implementation
>>>>     must explicitly also have support for 1.x.
>>>>
>>>> Btw: pretty sure that if i go back to my domain (IP Multicast for example),
>>>> our text will likely not be any better, but TLS just has the biggest
>>>> interest
>>>> surface so it makes most sense to encourage authors to write the most
>>>> easily
>>>> read text.
>>>>
>>>> Cheers
>>>>       Toerless
>>>>
>>>>
>>>> On Thu, Aug 05, 2021 at 03:57:07PM -0700, Eric Rescorla wrote:
>>>>> On Thu, Aug 5, 2021 at 3:52 PM Toerless Eckert <tte@cs.fau.de> wrote:
>>>>>
>>>>>> Another way to educate what you may consider to be "non-core"
>>>> readership,
>>>>>> is maybe some form of "TLS operational considerations". Your prior
>>>> answer
>>>>>> about that TLS server cluster consideration would also nicely fit into
>>>>>> something like that. Maybe something for opsec wg..
>>>>>>
>>>>> This is in the next section:
>>>>> https://tools.ietf.org/rfcmarkup?doc=8446#appendix-D.3
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>
>>>>>> Cheers
>>>>>>       Toerless
>>>>>>
>>>>>> (*) Not sure about the number. Could have been egyption or chinese
>>>> history
>>>>>> ;-)
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 05, 2021 at 03:23:42PM -0700, Eric Rescorla wrote:
>>>>>>> On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert <tte@cs.fau.de>
>>>> wrote:
>>>>>>>> Thanks for the explanation.
>>>>>>>>
>>>>>>>> My main concern was just to understand clearly what requirements
>>>>>>>> have to be written into RFC when one wants to ensure that TLS 1.2
>>>> needs
>>>>>>>> to be supported as the fallback in a particular solution.
>>>>>>>>
>>>>>>>>    With TLS 1.3 not mandating support for TLS 1.2, in such cases one
>>>>>>>> still needs to write MUST support TLS 1.2
>>>>>>> That's correct.
>>>>>>>
>>>>>>> when one thought
>>>>>>>> a MUST TLS 1.3 might have sufficed (assuming it included TLS 1.2
>>>>>>>> support). A bit more explanatory text in 8446 might have helped.
>>>>>>>>
>>>>>>> TBH, I think this is pretty clear in the document. We don't generally
>>>>>> expect
>>>>>>> that support for version X includes support for version X-1.
>>>> Moreover,
>>>>>> there
>>>>>>> is text in the document which doesn't make much sense if you couldn't
>>>>>>> just have a TLS 1.3 stack:
>>>>>>>
>>>>>>>    This document defines TLS version 1.3.  While TLS 1.3 is not
>>>> directly
>>>>>>>     compatible with previous versions, all versions of TLS incorporate
>>>> a
>>>>>>>     versioning mechanism which allows clients and servers to
>>>>>>>     interoperably negotiate a common version if one is supported by
>>>> both
>>>>>>>     peers.
>>>>>>>
>>>>>>>
>>>>>>> Or
>>>>>>>
>>>>>>>     TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627
>>>>>>> <https://tools.ietf.org/rfcmarkup?rfc=7627>]
>>>>>>>      extension which digested large parts of the handshake transcript
>>>> into
>>>>>>>      the master secret.  Because TLS 1.3 always hashes in the
>>>> transcript
>>>>>>>      up to the server Finished, implementations which support both TLS
>>>> 1.3
>>>>>>>      and earlier versions SHOULD indicate the use of the Extended
>>>> Master
>>>>>>>      Secret extension in their APIs whenever TLS 1.3 is used.
>>>>>>>
>>>>>>> -Ekr
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Also, the immediate status change of "obsoleted by 8446" may
>>>>>>>> make readers think that TLS 1.3 can take care of migration
>>>>>>>> from TLS 1.2 all by itself, when indeed it can not unless you
>>>>>>>> still also mandate implementing TLS 1.2. Of course we do not
>>>>>>>> have a better keyword vocabulary. Something like "Sunset by: 8446".
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>       Toerless
>>>>>>>>
>>>>>>>> On Thu, Aug 05, 2021 at 09:16:37PM +0000, Salz, Rich wrote:
>>>>>>>>>>      I am trying to figure out if every implementation compliant
>>>> with
>>>>>>>>>       RFC8446 is also necessarily interoperable with an RFC5246
>>>> peer,
>>>>>> or
>>>>>>>> if this
>>>>>>>>>       is just a likely common, but still completely optional
>>>>>>>> implementation choice.
>>>>>>>>> It is possible to have a single stack that implements TLS.[123].
>>>>>>>> OpenSSL, among many others does this.  Some have implemented ONLY
>>>> TLS
>>>>>> 1.3;
>>>>>>>> that code tends to be cleaner (in a nerd esthetic sense) than code
>>>> that
>>>>>>>> implements multiple protocols. Some servers even "hand off" pre-1.3
>>>>>>>> protocols to separate implementations (libraries); FB and Amazon
>>>> used
>>>>>> to do
>>>>>>>> that.
>>>>>>>>> The wire protocol for TLS 1.3 uses some deliberately-reserved
>>>>>> extension
>>>>>>>> fields so that a server which doesn't do 1.3 can fail cleanly, and
>>>> a
>>>>>> server
>>>>>>>> that DOES will work. And also the other way, a 1.3 client can work
>>>> fine
>>>>>>>> with both a 1.3 server and a 1.[12] server.
>>>>>>>>> It's easy to rationale 1.3-only for clients. It is harder to
>>>>>> rationalize
>>>>>>>> 1.3-only for servers if you are intending those servers to be
>>>> generally
>>>>>>>> accessible on the public Internet.
>>>>>>>> --
>>>>>>>> ---
>>>>>>>> tte@cs.fau.de
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> TLS mailing list
>>>>>>>> TLS@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>>>>
>>>>>> --
>>>>>> ---
>>>>>> tte@cs.fau.de
>>>>>>
>>>> --
>>>> ---
>>>> tte@cs.fau.de
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls