Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

Christopher Wood <> Thu, 15 June 2023 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBC49C151080 for <>; Thu, 15 Jun 2023 13:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.202
X-Spam-Status: No, score=-6.202 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b="wcluhrPy"; dkim=pass (2048-bit key) header.b="f5WaJ7wP"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B_AVhAw8HQAt for <>; Thu, 15 Jun 2023 13:37:56 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 430E0C15107F for <>; Thu, 15 Jun 2023 13:37:56 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 90E365C01AF; Thu, 15 Jun 2023 16:37:51 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute2.internal (MEProxy); Thu, 15 Jun 2023 16:37:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm2; t=1686861471; x=1686947871; bh=RZ2ERNDhi+zCNTLEahPbmk/oi EsNXvMvJ2WN4WPH718=; b=wcluhrPyyT00XAPtlvlpQlvYU0lpnn+u+VapiofNR ZAspr1QW12K0QaFIbFVv4m3r6HLKs2UzJmNrAnagZxgdSLH1YN1JsPuTXhMttuKy lvJ1aXxNnSu/NU3QjLOv2JToV2EiBa1BF9cj/IlIUg2dYoG2BgLTnrWsePWH0INO /L0QKzDZIB0wFjBkmjQWgv8Zp1noXC4Z7wHu1T3rbDQi2sW6b3tcXuOgfJjWZkxO 03vasTQbBYiyfK42xxSR4DVNU0FQ1CAQpgOPpieQsXFroBzRqAsQYQ3Cb4fWMXTf 3TbMaYBHk4RQ1ww6tQE09UReBv+ypb3eswj4G6OLalf6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1686861471; x=1686947871; bh=RZ2ERNDhi+zCNTLEahPbmk/oiEsNXvMvJ2W N4WPH718=; b=f5WaJ7wPrBuwkAXVt8B5MDzQI5ufVZS2ehIsXcfFUNl+rTRN4sE 6d1CEzlhOsvqOfWJT/pCaTDWXjstNy0k30IILpZ+XAm2opB6NMlsi+b+LLANQM07 0YpEsalY04jG/1IbYWLU3lgMPLEdpFcsy4F07I1HSOiIlvnNKgZepyVda/m8J2xo StZ8pOeWWLJqsEjvTpAW+WwG6GYCKv/ApRdZNX0GLYnUnM4yyKjebHliB7WNETGQ lD5vj1Xc9pBqnoLiK58x/x5W2etw7n1GtPurlAP5ZHDNqWRvrnLuQVVfe93gHpOt kXYJaetX5bdrQtdT0U01ksHojWS0MrcdvPA==
X-ME-Sender: <xms:n3aLZI7i1tNjeWS60ui_6GAhYpn3TsaD52T4bF5Wb6J6I7VvkJERig> <xme:n3aLZJ4m6IgvPC513bAUpt4uaHO8uQRk5CbmQfUrccPLiMRpioKX-Y6heoqI31wC3 mmu2Ptr9OWMMm8lFO8>
X-ME-Received: <xmr:n3aLZHe9knKvL3ms8nKy1IvFyROBM8SQEf8fV2qR2nz5-CwjvlD_fuYtSIXadoXJwfBwIhUPP5z3V1gx4eEt3D-ksqngRjdP8IJ_e2gZcVMP5UC3xsh-Sg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedvvddgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enqfhnlhihuchonhgvuchprghrthculdehuddmnecujfgurheptgfghfggufffkfhfvegj vffosegrjehmrehhtdejnecuhfhrohhmpeevhhhrihhsthhophhhvghrucghohhougcuoe gtrgifsehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeektdff ieffgffhieefjeevvdeuieevkeelffejleehveffgefhfeevfeelfeffgeenucffohhmrg hinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:n3aLZNIBS79orC4nDc-gWyIsNoN9TB6QmCsP9gUCpRabRqu_QudOeg> <xmx:n3aLZMI2btzQ7H4aqQduH5FdETWnzrTjdBPJt-oG0ms4xOgoYAS5Cg> <xmx:n3aLZOw43heGNSaNqT4abcok07huW4TwhYb5WwQTaarvn0trMmRBWQ> <xmx:n3aLZGi1fQvKO3fkw11JX6ZZbjAz-iG_J2STGitNa3Xb6XmE4jKBmA>
Feedback-ID: i2f494406:Fastmail
Received: by (Postfix) with ESMTPA; Thu, 15 Jun 2023 16:37:51 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-2BA2260B-D50B-42F4-9372-70131706D1A8"
Content-Transfer-Encoding: 7bit
From: Christopher Wood <>
Mime-Version: 1.0 (1.0)
Date: Thu, 15 Jun 2023 16:37:39 -0400
Message-Id: <>
References: <>
Cc: Rob Sayre <>,
In-Reply-To: <>
To: Eric Rescorla <>
X-Mailer: iPhone Mail (20F66)
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Jun 2023 20:38:00 -0000

On May 22, 2023, at 6:49 PM, Eric Rescorla <> wrote:

On Mon, May 22, 2023 at 1:09 PM Rob Sayre <> wrote:
On Mon, May 22, 2023 at 12:59 PM Christopher Wood <> wrote:
We trust the editors will faithfully enact all editorial changes they agree with as the document moves forward in the process. If there were non-editorial comments that we overlooked, could you please resurface them?


I made these comments about 1.5 months ago, so I hope it doesn't seem like I'm requesting a particularly quick turnaround.

Yes, this is my mistake. I just went through the Github issues and forgot to deal
with this e-mail. I will create a PR for these.

There were a couple obvious corrections EKR agreed with, but aren't done. These should be fixed before IETF Last Call.

The one real problem (imho) with the document is nested MUST requirements:

EKR called this "guidance", but RFC 2119 says MUST is "an absolute requirement". The document needs to use the 2119 requirements language correctly. I understand the goal, which is to preserve wire-format compatibility in older TLS versions, even though they have security flaws.

As you indicate, the context here is that RFC 8996 forbids TLS < 1.2, but
we know people might ignore that and thus this text is intended to provide
requirements for people who do so. It's an inherently contradictory situation,
but also the one we find ourselves in.

With that in mind, you seem to be making three points:

>   Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>   versions below 1.2; implementations which do not follow that guidance
>   MUST behave as described above.

Your complaint seems to boil down to the word "guidance", but the word used there doesn't have normative force, so I think this is an editorial issue.
I agree we should also cite E.5, and I can cite that in my PR.

Appendix E.5: > > The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246], > > and TLS 1.1 [RFC4346] are considered insufficient for the reasons > > enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT > > be negotiated for any reason. > Here, I would end with "...for any reason in applications that require a > secure channel."

I don't think that this is a good change. 8996 just flat out prohibits them and so we should match that.

> > Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- > > HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an > > SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT > > RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in > > order to negotiate older versions of TLS. > > Without the little trailing text I added above, this seems a little > contradictory. The thinking here is the document says this is NOT > RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS > 1.2 here.
I don't see the problem here. You MUST NOT negotiate TLS < 1.2 and you are NOT RECOMMENDED to use  the SSLv2 CH to negotiate TLS 1.2.

Perhaps your objection is to the use of the plural "older versions" but again, we know that some people will ignore the E.5 requirement and the point here is that even if they do so, they should still not do this.

With all that said, if there is WG consensus to make these changes, I'll of course do so. Deferring to the chairs on how to proceed.
Sorry for the delay. This slipped through the cracks. Given that we went through this process with the text as-is, I think we can live without this change. 

Chris, for the chairs