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

David Benjamin <> Mon, 25 October 2021 22:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93D263A1477 for <>; Mon, 25 Oct 2021 15:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rdjlDO2v1ftG for <>; Mon, 25 Oct 2021 15:52:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 052A13A10A9 for <>; Mon, 25 Oct 2021 15:51:45 -0700 (PDT)
Received: by with SMTP id 187so12321069pfc.10 for <>; Mon, 25 Oct 2021 15:51:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u0cuzU6PMH38C9ihsrCo3ziy5iLEw/V1T4y0yHE2fKE=; b=KEn61xoAR4y/HjBnUsXU596oOEi4u7P95bevxLGEjU5vygWQl34zRdYk9Wtx2Fz26V 4SLWE+Z4iVwoDGpfZLUWsurDfrdQgaNqKd0PqnbzTC5JDMOsIxEuFtalfbqcioicYIoL uePY1abIarbO5m25np61Ab9KASRd2eqYCOYR4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u0cuzU6PMH38C9ihsrCo3ziy5iLEw/V1T4y0yHE2fKE=; b=R5wRWiGim3y7qsLbi3Mt3fUKZXtSIqxY+u7GG/AEMSy9/+LkaKoNuA2cAYKXWn1/BN Ooa991heLx4e4HerxVkgR7qjWoDnIKrTBctb2yKyI1ya5FwhpGoyxUzPmeGnLJdpKq5H bfqMdPVJ/gh7qur2IRb8blB3f+Of45aDxjDIsOQlwTAfYD2hYKNljMEU84YfRmj2K1+D fzcY6++RUvCNvdYvSZ/CQjB4kQsm2LSKb4ev3o2+zxCxVyoQ/IDM5IhA/zHzWCVoIcu+ Y77HbC6ENIKL23uFh3zdCNYGKD7rKQlomei+qZodfmUCxoYLXlJ05PC5Nj5GULc2f0sV 4coA==
X-Gm-Message-State: AOAM5330wwqc83MakTZAQNaJdlQy26NzuD0TPY8jRyMDApoHZwSpPmfL t1N4SOhRcmi9Vw8uPKDL8/+MrBWTWyikJNGaoO+IaAFotRNb
X-Google-Smtp-Source: ABdhPJyllareuaBLxbcWP/5k+ffrOIpJ9PSn62Kaw7WttL3Nw6/4eMU3rpFwrp3K3uc9Dls5AS4oxdGt6C55bBqgpqU=
X-Received: by 2002:aa7:888d:0:b0:46b:72b2:5d61 with SMTP id z13-20020aa7888d000000b0046b72b25d61mr21083573pfe.73.1635202304037; Mon, 25 Oct 2021 15:51:44 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 25 Oct 2021 18:51:27 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000789cdc05cf35349c"
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: Mon, 25 Oct 2021 22:52:57 -0000

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

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 <>

> 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