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

David Benjamin <davidben@chromium.org> Mon, 25 October 2021 20:01 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 646993A0C7C for <tls@ietfa.amsl.com>; Mon, 25 Oct 2021 13:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id U_8_bn-Utblh for <tls@ietfa.amsl.com>; Mon, 25 Oct 2021 13:01:32 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 7A7353A0809 for <tls@ietf.org>; Mon, 25 Oct 2021 13:01:29 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id u13so4023657edy.10 for <tls@ietf.org>; Mon, 25 Oct 2021 13:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=sMow5wZRXlFAP4W9rpzffK8LK6fLyrCF6U3MjUJCUlo=; b=lyHGptmdZFfQWeIN51FH2+wR3Z7GaWVm6HW/ctCyM4F9j+XAoCPE2bhLsTUSufCO/Y LUcncMzhu8VHukWuNanwpWM+Ih7Z/L00NdSdF7iDR1BHreKkkU5Pvqv0RYoq4jS9sHSL ZQP7LX6EjdpvlsV9KJWCOxKo0xAqNtsU0e5A0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sMow5wZRXlFAP4W9rpzffK8LK6fLyrCF6U3MjUJCUlo=; b=sVxkvlhoyVmQaQB7MoAPORWL/PFCeXb0zYMbWKVJ8eg11L18ZKgpVRo6zHvcMoNV95 pIEfBqwOFnj3Hx8dh6ijkqwdhfc1NoLFLrMW2teezj0yCKqfLhKH1n+u8GCZsw2Zhwdj 1sQHvEJoqoyD8jyy4YWoGw62GIzjsN4AU6sH+x7LrxhV0GBPCpg16D6LZtC38njutw95 Vcn5QwYPFozH5l1i+1khYRnCguoDU5lVBAmEo22laDA+m+RDSRXxHPwQ/kf/n8AM9s3f EKBnb404F7kwiMDqJaY53NB2m9XBpMIZdGQFxIeHlj8fGVT7b9PpkXWQXCtChqnN/J+l zWeQ==
X-Gm-Message-State: AOAM533CKFCQCELrHHfAeslsE/JCzGSazTjs1fL8kS7M4uAkD2znmUlG s/O3FvhxydHQP/SYLdBWe12UNcQgljQbfm20evkhilz7ORYi
X-Google-Smtp-Source: ABdhPJxSghWzk0N9HfzduI92KlNP+RVr4eneQMKYRlXr7YIGkDcLveSMVYlfflLiXtrKT5jRuKvM+5EXVex3eEf7DH0=
X-Received: by 2002:a05:6402:4401:: with SMTP id y1mr29463375eda.44.1635192084066; Mon, 25 Oct 2021 13:01:24 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Mon, 25 Oct 2021 16:01:07 -0400
Message-ID: <CAF8qwaDi19sp_hg0mTySRGEf46kHfc1bCKee4bH+98QQmxtjog@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005030d105cf32d3c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VbvqXoZnXxttUyNsM2pMoTLqaXs>
Subject: [TLS] Spec issue with RFC 7627 (EMS) and resumption
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: Mon, 25 Oct 2021 20:01:39 -0000

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


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?