Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

Achim Kraus <> Tue, 26 October 2021 05:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA7E03A1091 for <>; Mon, 25 Oct 2021 22:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.448
X-Spam-Status: No, score=-5.448 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, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VHlj9OOnT5om for <>; Mon, 25 Oct 2021 22:05:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7111C3A107F for <>; Mon, 25 Oct 2021 22:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1635224718; bh=qrkcQv65jeUO+vLarNNlJ23x5HQdxuqGfSQ5SeEpNSA=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=NRRyaACkBezxtKokDfqgy2kT+txCkqXD6Z5LrNsoMHiz2FFr4Oq6kHSvBTY5STCav EYtfi2Ekmjqtn2EB/+0hwRfOOlJ2xdicXi5fKoRvukl+wT6+Bs0xxTYspqppAjLJRo 6V3Kfcr/9lc8LK55sWU4Nd01uMUGX5J5f2MKExEw=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1M1Ycr-1mgbYb1Iqp-0038fQ; Tue, 26 Oct 2021 07:05:18 +0200
References: <> <>
Cc: "" <>
From: Achim Kraus <>
Message-ID: <>
Date: Tue, 26 Oct 2021 07:05:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:vko3TUgzueN1MqADugw6/87wv7H0gsqDyNwhtjmC/i8+v+YgAeP B45/kfOkDJnXFmGagKV7wB20iO36O//hXlJq08h3vaRYvBnWfsjpTmd2FoVbUcg6b/lLUAO 8QV++cEOt2vD6AImSBL1HlJ329NbsFnXdeFi5lmLU7xUjQaKTqM/ISEskkE1hZEbgC2L2Uj hFuwNMrUFzhpPKwqnNO2Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mU3C+izWINA=:AjpllSre1VYRP8XP0AZfz3 CDvGPzFN6tlt/F6+VZ0zi8USBR8iR3FskHFWUpugKr+oQQxJM6CuKGthve7Kt7H/ws99ocxWl ZNkmw0Vvm2Jh25C97szmDNjQumMCmnysh/Z5fIrz3qCU/BkcjajJjZze5NBOTlwN8VkmVwUNE HyF3XRcdjJM4C9VjmtMNLlkinm0drhUKHEvprd3ziDHdvtcQYuv0XM/KhM1wtQT1GvFwUAYix eX2KJzW1AaaXbpwR8qKbfyfhlkxMpm0kLqfnyJh87qyrGr7SYFrznZp8Vh2q5HjEAHnu2C+Cl zhuv2+7BFNFx6Hnhq4iXA7ljhBS69FeoB9aAy8BU8u4EjGnr76/4BeZisE3RVyEQPxha7xpan P3dj0bsd8wUM2TPuTc02PvvB50uCpE4fmmNg29MZsJXSYhhbx+WIhnpKT5gzjVgz+1oeXRq/3 7x4IIqcHJsijA45ZXv9YxGo9iaUi38bIuUf2wfPgK2mNzEZZhQUGA/SDiE3YKKuCEV6lERAAQ sN0rh6skRqqzG2pLPRA812y+7JzbpUWdhMD6qfMNqZs4/cuvvbO/3Do25+vQLBQJHAOae69P3 9ccakXD5kVU2K1wwTgnuqpSysXoLTdn0Kl19m/LcQmLGVzecyetc6nSSBktGj3RMyCP1A5SCD dlh0KFgD/rrnSAO82oZ5hC3uzLKbhwrKcXocLL1xqN+YFWDql16PQT8cfwZDiQ0vbRj0wXhGy UqkVLbNWgBXzG0Vcm/Cf9eyqSYdixNemsqgK5smI+iAUxBQ33B0adR9XfQCi+U4LOU6Hf+7Tj ChwuZtpAr1ngWsrAx4WY3WOCVkApDbZBNXDWoci+Yws3by9mS9TaJZiWx8F1RKxpyLGx8G6LV +gNBbR06JorgEeScL3sjFhefhJwVSK9wGVqYShXMLhQpCf5Vhvj0Q0GjB8gSDmwS9X0uyS63A rlEWk+GUzeRJlriOauxmCyzjrakTtBbtyQYzQ7TUfWXB29iVX0oGmorjwnmaerwYzDsZ+de+i lRirjySXlXVW9gALeyyve0Y8hk+vXqxdfiBYh8+9Y0NFsqiNsl03j9OY0CV3Ymj8t3XFFN1dN LPkhR38iVAIuTg=
Archived-At: <>
Subject: Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Oct 2021 05:05:25 -0000

Hi David,

if you're on it, maybe it's worth to consider my question from January
2021 as well.

 > If the client follows this guide, it falls-back to use a full handshake.
 > If the client doesn't follow this (maybe, the client is not aware of RFC
7627), the server SHOULD aborts.

 > Why SHOULD the server not (also) just fall-back to use a full handshake?

For more details see:

best regards
Achim Kraus

Am 26.10.21 um 00:51 schrieb David Benjamin:
> Here's some possible replacement text for that paragraph:
> """
> In some deployments, a legacy client or server may be exposed to a
> session using extended master secret. For example, a group of servers
> sharing a ticket encryption key may be in the process of enabling this
> extension. If such a session is used in an abbreviated handshake without
> the extension, a newer peer will fail the connection, as described in
> Section 5.3. To avoid this, legacy servers SHOULD ignore such sessions
> and continue with a full handshake, and legacy clients SHOULD NOT offer
> such sessions in the ClientHello.
> This can be implemented by ensuring legacy implementations do not
> recognize sessions using extended master secret. For example, the
> sessions may have a higher internal version number or, if the older
> implementation rejects unrecognized fields, include a new field. If this
> is not possible, deployments may deploy a new session cache or ticket
> encryption key alongside the new version.
> """
> Unfortunately, "session using extended master secret" is a bit of a
> mouthful, but section 5.4 didn't define a more concise term.
> On Mon, Oct 25, 2021 at 4:01 PM David Benjamin <
> <>> wrote:
>     Hi all,
>     In diagnosing an interop issue, I noticed RFC 7627 did not describe
>     the correct server behavior for EMS very well. Seemingly as a
>     result, some server implementation has gotten this wrong. I'd like
>     to fix this in the spec so this doesn't happen again. I think, at
>     minimum, we need to replace the last paragraph of section 5.4.
>     The issue is a server that /doesn't/ implement EMS, when presented a
>     ClientHello containing a ticket or session ID by a server that
>     /did/ implement EMS, must ignore the session and continue with a
>     full handshake. Failing to do so will trip the client check in
>     Section 5.3, "If a client receives a ServerHello that accepts an
>     abbreviated handshake, [...]". This is important to meet these three
>     properties:
>     - If the client and server both support EMS, the connection must
>     negotiate it.
>     - On resumption, the EMS status of the connection must match the EMS
>     status of the session
>     - In order for EMS to be safely deployable, it must be possible to
>     roll EMS out gradually, or roll it back, without breaking
>     connections. This means a mixed pre-EMS and post-EMS server
>     deployment must work.
>     Note that, although this behavior is only visible at the pre-EMS
>     server (not directly in scope for this document), it is actually a
>     requirement on the post-EMS server. When the post-EMS server issues
>     a session, it must arrange for the pre-EMS server to ignore it. For
>     example, if the pre-EMS server rejects sessions with unparsable
>     fields (the safest option), the post-EMS server can add a new field
>     to the session state serialization. Failing that, it can bump some
>     internal version number. Another strategy is to rotate session
>     ticket keys alongside the version, but this can be tricky the way
>     deployments and software updates are often split.
>     There's an analogous, though less likely, client scenario that a
>     pre-EMS client must not offer a post-EMS session. Otherwise it will
>     run afoul of a server requirement. This can be relevant for clients
>     that serialize their session cache.
>     As far as I can tell, RFC 7627 does not specify any of this. The
>     first paragraph of section 5.4 talks about adding a flag, but
>     doesn't talk about how pre-EMS servers interact with that flag. The
>     last paragraph discusses this scenario, but says something very
>     strange, if not plain wrong:
>         If the original session uses an extended master secret but the
>         ClientHello or ServerHello in the abbreviated handshake does not
>         include the extension, it MAY be safe to continue the abbreviated
>         handshake since it is protected by the extended master secret of the
>         original session.  This scenario may occur, for example, when a
>         server that implements this extension establishes a session but the
>         session is subsequently resumed at a different server that does not
>         support the extension.  Since such situations are unusual and likely
>         to be the result of transient or inadvertent misconfigurations, this
>         document recommends that the client and server MUST abort such
>         handshakes.
>     <>
>     First, the "MAY" is immediately contradicted by the following
>     "MUST", and by section 5.3. It seems it should have been an English
>     lowercase "may", not a normative RFC 2119 "MAY". It is also wrong in
>     calling this situation "unusual and likely to be the result of
>     transient or inadvertent misconfigurations". Rather, it is the
>     natural transition state of any large server rollout. I think we
>     need to delete that entire paragraph and replace it with text that
>     describes the rules above. If we were doing a whole new version of
>     the document, I think the text could do with reorganization. But
>     that may not be worth doing, given folks should be using TLS 1.3 now.
>     Thoughts? I can put together some replacement text if folks agree.
>     What would be the best way to do this? Just an erratum?
>     David
> _______________________________________________
> TLS mailing list