IETF Logo Mail Archive

Re: [TLS] What is "completed handshake"?

Martin Thomson <mt@lowentropy.net> Tue, 09 August 2022 06:51 UTC

Return-Path: <mt@lowentropy.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 D01FDC15AD43 for <tls@ietfa.amsl.com>; Mon, 8 Aug 2022 23:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=aIUUukGD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AXYOwrDP
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNQ_aFdgpHmw for <tls@ietfa.amsl.com>; Mon, 8 Aug 2022 23:51:05 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 80C14C15A73B for <tls@ietf.org>; Mon, 8 Aug 2022 23:51:05 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8540C5C00ED for <tls@ietf.org>; Tue, 9 Aug 2022 02:51:04 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 09 Aug 2022 02:51:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding: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=1660027864; x= 1660114264; bh=3QLOUeJhAEzE5H8NEcEvpNPsHyyZFamGQzO/0Dc3T28=; b=a IUUukGDUonpchOIfF/zgP0rEJQYBvmrQnY0SorCCI7vnJwyz4s++ViwISdB2vNsX iS0r9qNsQ1PcTeik6pTcgY4lgyGMF+2wRER5jsGP1LYwUHVjvKGZFz8NyDV+To3S RoeY1sG662VyNXAvTnU1oQTzjOByaj6KGQAwgNQUYrBVDp0ncCADJ9NbrdiNahvz KXjAir5edpSgaZ1w/WDxzC+lAqN6edmapCuWEMUyIh+4KZg4YZg+jSsnR5ZrkJqV O1P5a/XJqzWI4DSn5aqSczaXv463lbjmI5y1XPywWJiLORZz1WNHKO5RteGm2fTZ DGMl7sVi3Q8sv5eie2Jcg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm1; t=1660027864; x=1660114264; bh=3 QLOUeJhAEzE5H8NEcEvpNPsHyyZFamGQzO/0Dc3T28=; b=AXYOwrDPyxgXdXziZ 6YixziDHRmH01tGGRrGKbHADz7LHeQkYGyV/fIfxDx7vxTi0p7foO6OSYc0vFENG S6RUzhQfmldJvtyIypTAO8ROaOfvdlQHpvdu80hW2dYe3mFifx5vyxL80sdEEc0D jn+uzLRFU5KeWLMCYg3TNL6e7zXy8IZUkQZXctwvBSy8rJzKIoN3uNgBp3+d5ueV z3MmPwMuJyon86FDW0HOJS6KJ0QZHfr2eEjhpdqAxxjfAy91N/w49DQJFEv67YNk UR7bHc7T/0gEF9NzqDFDdO+vE6CAXftkUgy1G1+xC78bLRLMmjeuJdIQCJ9kprOt D9mPg==
X-ME-Sender: <xms:2APyYju3OhuyiFRHoqsr2yG7MFBigQyv__jpLmJuodJIqTvQWGb88A> <xme:2APyYkci-bRdS3u4q6eZ6-EiAoR7r3F20H7nSx7hG1aUOjiKqSQFtFka53EvMyZth rTZAcnJL9wp93yc_lM>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdefledguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmthes lhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltd egleehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrd hnvght
X-ME-Proxy: <xmx:2APyYmy6swXEpllrqlGIBskW92KUFmHZmEzHv9NPN3bYb2D01o7CGA> <xmx:2APyYiPUdq9mOhijq5NwqhhxAfRXrKdq8Em6llEot_EH3Yde5VHG0A> <xmx:2APyYj-Jt56BDm7xFUGYJ0IDaWXaKp8xiFNmiMwWeb1DbOoc9G5XlQ> <xmx:2APyYmKuNqfHuxrvhJDeT-f0g0oxj73BN953kVBsFnM937hBIsZVQg>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 46E4D2340077; Tue, 9 Aug 2022 02:51:04 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-758-ge0d20a54e1-fm-20220729.001-ge0d20a54
Mime-Version: 1.0
Message-Id: <1cde19df-e130-43be-b447-41106dafa179@beta.fastmail.com>
In-Reply-To: <CA+_8xu2z7jNZt3EVb71b5usU13ggXHBoGbNvVL+S9xkBqiUpMA@mail.gmail.com>
References: <CADqLbz+EJAWpAF0bBZn7DOmPwT7ZkfvNsj+uPxP3qenG26fWhQ@mail.gmail.com> <CALZ3u+aJE-ha2YFQ62fNaZUQy6yUbABAt+uBgW8h47fgkp_tiQ@mail.gmail.com> <CA+_8xu2z7jNZt3EVb71b5usU13ggXHBoGbNvVL+S9xkBqiUpMA@mail.gmail.com>
Date: Tue, 09 Aug 2022 16:50:44 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/O9GHniGpNH-Mbd5PwPdLfMewubA>
Subject: Re: [TLS] What is "completed handshake"?
X-BeenThere: tls@ietf.org
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." <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, 09 Aug 2022 06:51:10 -0000

On Tue, Aug 9, 2022, at 16:36, Ben Smyth wrote:
> On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote:
>> "Upon receiving the server's messages, the client responds with its Authentication messages, namely Certificate and CertificateVerify (if requested), and Finished. At this point, the handshake is complete"
>
> I stumbled with this. 

That seems clear enough to me.  At least from the client's perspective.  Presumably the server has to receive the client's Finished to consider the handshake complete.

> OpenJDK reports handshake completion twice.

My first reaction there was "yikes!".  But on a second read, that's not so bad.  The (sometimes) second signal to the client on receiving NewSessionTicket is a bit weird, but aside from being a bit odd, it's documented, so that's on them.  It's weird, but as long as clients are aware of the strangeness, it seems like the risks are contained.  Even when clients aren't, the risk is that the client does something two times, but then the prevalence of NewSessionTicket means that clients are highly likely to encounter the second signal and notice any problems it causes.

v2.23.0 | Report a Bug | By Email