Re: [TLS] RFC8446 backward compatibility question

Valery Smyslov <smyslov.ietf@gmail.com> Fri, 06 August 2021 08:24 UTC

Return-Path: <smyslov.ietf@gmail.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 5D1E83A2490 for <tls@ietfa.amsl.com>; Fri, 6 Aug 2021 01:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=gmail.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 BC0HDz594h3D for <tls@ietfa.amsl.com>; Fri, 6 Aug 2021 01:23:56 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 9FBA83A248E for <tls@ietf.org>; Fri, 6 Aug 2021 01:23:56 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id m12so9972649wru.12 for <tls@ietf.org>; Fri, 06 Aug 2021 01:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=NsalM2pz5nQDdSz01Ti7Fl02fIlSu794ASGQ8e7jz0Q=; b=o0Ll4AdtKAJxkQR4sm7AvpIlv6NFpK16UbSfJ3SSoWX4jPiXegORWfPLgROJp+CAxJ MyWsK08hJV4npI+9vlA5w0sPFD1b0wd2n2OS4zgdAWoChl8XSsIAd5sxzY+pkDeHr3RC urv0+9rdg/jTLQPZLg7yWigfxsJ/G47r+PrQ3bSeLybLZ3dQHwCmLMaDVl7Bog6wQtg9 w430fm4NGbPl9Z3D4YJFLpUHx6TAjkUF+gXYWLH7i8/93swUdm1FB9Q0xGw/u0gtM2Od IGyCnQIGkHD0Khxd55OJNJxdRvMlMPDjQc8fSk3aJA11VSeMDM5duUHBzi9C7feLltFd 6PZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NsalM2pz5nQDdSz01Ti7Fl02fIlSu794ASGQ8e7jz0Q=; b=oE9U0kkplJqQp0fUnn+UQY6LYGBDxRrXkFE6i5lvKva1CDG2KIjHS485+L/QmqrmU/ PqrRde4zZlcxmt2ZQaB9wDC0oNafJpF1+EX4BMnw1s02aW2mbkpZdpnJf7FHCa9Jn/xv 6j074TOR62MKd9RZOvDxcwVtmcmr9D0Ep2krxoh3lFy+F+1y22ddwAbooswPYf4UX2i4 Smazv76VawW/55T6BZOEXzWuc7mMBo4z1WD41VwPOqiszj70vkkO9G8Sm0QhoX2xZpXu tcjjtciYfQ2JdQuBjeXfgnnCj2QzzIBqQ6TH6moAKTYXsuGGKx+2kaTH2uM8+u4+cD4+ 4Csg==
X-Gm-Message-State: AOAM532FeHR50t/Cfq2D5YbXRc3QMMzILhZOhsDvcNd83/QMku/iy0XU J6Tg/Nl8Ik9UmtPG+u1i1rsu5rD0KAE=
X-Google-Smtp-Source: ABdhPJwed58mnLzS4IAp3dPZULQWrR6p8G+8KkqIakJ5jdFv1+nEKTzI5aJyLnxG+vWX5C1H4yNcrw==
X-Received: by 2002:a5d:4803:: with SMTP id l3mr9569246wrq.131.1628238233754; Fri, 06 Aug 2021 01:23:53 -0700 (PDT)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id k18sm10936258wms.1.2021.08.06.01.23.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Aug 2021 01:23:53 -0700 (PDT)
From: "Valery Smyslov" <smyslov.ietf@gmail.com>
To: "'Toerless Eckert'" <tte@cs.fau.de>, "'Eric Rescorla'" <ekr@rtfm.com>
Cc: <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>
In-Reply-To: <20210805225244.GE57091@faui48e.informatik.uni-erlangen.de>
Date: Fri, 6 Aug 2021 11:23:54 +0300
Message-ID: <223d01d78a9c$663c5440$32b4fcc0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKobkd95zAbWwBLX1a6cyvNHbi8lAFDTEw0AJI709cB08zzIAJWixByqZRbAQA=
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5niEQbwSmk7YSgzv28IBcfl39rI>
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 08:24:01 -0000

Hi Toerless,

> Eric,
> 
> What you call "pretty clear" is IMHO quite indirect. And yes, i tried
> to find evidence and stumbled exactly on that second example and then was
> not 100% sure...
> 
> My comments where just trying to provide friendly feedback from
> a TLS uneducated reader. Remember that TLS is just recently starting
> to proliferate into markets like IoT, so an expectation of knowledge about
> 6000 years of TLS history may not to be expected for broadest readership
> of the RFCs (*).
> 
> 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..

UTA WG is concerned with using TLS in applications.
In particular, RFC 7525 (currently being updated, see draft-ietf-uta-rfc7525bis) 
gives some operational recommendations on supporting different versions of TLS.

Regards,
Valery.

> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls