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

From: David Benjamin <[email-masked]>
Date: Mon, 25 Oct 2021 16:01:07 -0400

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.

https://datatracker.ietf.org/doc/html/rfc7627#section-5.4

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

---

From: David Benjamin <[email-masked]>
Date: Mon, 25 Oct 2021 18:51:27 -0400

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 <[email-masked]>
wrote:

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

---

From: Achim Kraus <[email-masked]>
Date: Tue, 26 Oct 2021 07:05:17 +0200

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:

https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/

best regards
Achim Kraus

Am 26.10.21 um 00:51 schrieb David Benjamin:
> 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.
> """
>
> On Mon, Oct 25, 2021 at 4:01 PM David Benjamin <[email-masked]
> <mailto:[email-masked]>> 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.
>     - 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:
>
>     <https://datatracker.ietf.org/doc/html/rfc7627#section-5.4>
>
>     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
>     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Tue, 26 Oct 2021 11:50:22 -0400

At least for an erratum, I don't think it makes sense to change that as
part of this.

I think your question is conflating a few things. Let me try to untangle
this, as this document is little confusing. It seems to be describing, via
SHOULDs and MUSTs, three different implementation profiles concurrently:
1. A client or server that negotiates EMS when available, but continues to
be compatible with legacy peers, resumption and all.
2. A client or server that negotiates EMS when available, continues to be
compatible with legacy peers, but only allows full handshakes with them. I
forget how 3SHAKE worked, but I vaguely recall that cutting out legacy
resumptions avoided a source of issues
3. A client or server that requires EMS on all connections, and is not
compatible with legacy peers at all. This way you can rely on the EMS
bugfix being applied.

Because these are all interleaved, it's a very hard to tell what bits
correspond to this profile and what bits correspond to EMS itself. I think
this was overambitious. Anything but (1) was implausible for most
deployments in 2016, because EMS only just started existing. I expect it is
still implausible for most, though I don't have metrics for the web. Hence,
if we were completely redoing this document (probably not worth it?), I
think it should be reorganized. :-)

> 7627), the server SHOULD aborts.

The client SHOULD you are referring to is for a client that implements (2).
If a client does not follow this, it implements (1). The server SHOULD,
however, says "If neither the original session *nor the new ClientHello*
uses the extension, the server SHOULD abort the handshake." That clause
doesn't apply to the client SHOULD in the first place because, whether the
client is (1) or (2), the ClientHello will signal EMS.

It does apply to legacy clients that do not implement EMS at all. Whether
the server continues, does a full handshake, or aborts depends on whether
the server wants to do (1), (2), or (3). Yes, if it picks (3) and aborts,
the server will not interoperate with a legacy client. That is exactly what
those servers would want. It is odd that the text only describes (1) and
(3) for the server in this case, not (2). But adding (2) in without a
rework will only make this complicated situation worse, so I do not propose
to address it as part of this fix.

---

From: Achim Kraus <[email-masked]>
Date: Wed, 27 Oct 2021 10:55:38 +0200

Hi David,

my question considers 2. ,
if one peer uses RFC 7627 and the other not (legacy).

Case 1:
- client using RFC 7627, server not (legacy)
-- client fallsback to full-handshakes

Case 2:
- server using RFC 7627, client not (legacy)
-- if the client tries a resumption, the current definition is, that the
server SHOULD abort.

In my opinion in case 2, the server SHOULD also just fallback to a
full-handshake. That's done by sending a ServerHello with a new Session
ID and the other handshake messages of a full handshake.
In the end, that prevents, that a client to have to execute a second,
then full handshake, as fallback.

best regards
Achim

Am 26.10.21 um 17:50 schrieb David Benjamin:
> this, as this document is little confusing. It seems to be describing,
> via SHOULDs and MUSTs, three different implementation profiles concurrently:
> 1. A client or server that negotiates EMS when available, but continues
> to be compatible with legacy peers, resumption and all.
> 2. A client or server that negotiates EMS when available, continues to
> be compatible with legacy peers, but only allows full handshakes with
> them. I forget how 3SHAKE worked, but I vaguely recall that cutting out
> legacy resumptions avoided a source of issues
> correspond to this profile and what bits correspond to EMS itself. I
> think this was overambitious. Anything but (1) was implausible for most
> deployments in 2016, because EMS only just started existing. I expect it
> is still implausible for most, though I don't have metrics for the web.
> Hence, if we were completely redoing this document (probably not worth
> it?), I think it should be reorganized. :-)
>
> The client SHOULD you are referring to is for a client that implements
> (2). If a client does not follow this, it implements (1). The server
> SHOULD, however, says "If neither the original session /nor the new
> ClientHello/ uses the extension, the server SHOULD abort the handshake."
> That clause doesn't apply to the client SHOULD in the first place
> because, whether the client is (1) or (2), the ClientHello will signal EMS.
>
> It does apply to legacy clients that do not implement EMS at all.
> Whether the server continues, does a full handshake, or aborts depends
> on whether the server wants to do (1), (2), or (3). Yes, if it picks (3)
> and aborts, the server will not interoperate with a legacy client. That
> is exactly what those servers would want. It is odd that the text only
> describes (1) and (3) for the server in this case, not (2). But adding
> (2) in without a rework will only make this complicated situation worse,
> so I do not propose to address it as part of this fix.
>
> On Tue, Oct 26, 2021 at 1:05 AM Achim Kraus <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi David,
>
>       > 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
>       > Why SHOULD the server not (also) just fall-back to use a full
>     handshake?
>
>     For more details see:
>
>     <https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/>
>
>     best regards
>     Achim Kraus
>
>      > On Mon, Oct 25, 2021 at 4:01 PM David Benjamin
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi all,
>      >
>      >     <https://datatracker.ietf.org/doc/html/rfc7627#section-5.4
>     <https://datatracker.ietf.org/doc/html/rfc7627#section-5.4>>
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>      >
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 28 Oct 2021 13:44:45 -0400

It depends on what the server is trying to do. If the server is trying to
mandate EMS, aborting the connection is correct. E.g. the full handshake
section then says:

   If the server receives a ClientHello without the extension, it SHOULD
   abort the handshake if it does not wish to interoperate with legacy
   clients.

Though I suppose the abbreviated handshake version is missing a "if it does
not wish to interoperate with legacy clients". Yeah, okay, this probably
also needs an erratum to add the right qualifier. Gosh this document is
confusingly organized.

On Wed, Oct 27, 2021 at 4:55 AM Achim Kraus <[email-masked]> wrote:

> >     <
> https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/>
> >
> >     best regards
> >     Achim Kraus
> >

---

From: Achim Kraus <[email-masked]>
Date: Fri, 29 Oct 2021 07:46:32 +0200

Hi David,

I'm still not sure, if there is just a misunderstanding:

For me, case 2, the support of legacy peers comes with using only
full-handshakes, and no abbreviated handshakes.

For the client the consequence is, to use full-handshakes with legacy
servers.

So, I would assume, that just the same applies for servers as well.

If a legacy client tries to execute a resumption handshake, the server
in mode 2 has two options to support such a legacy client according the
general rule to only use "full-handshakes" and not "abbreviated" ones.

- abort the client initiated abbreviated handshake in order to make the
client restart with a full-handshake (that's what the RFC defines)
- the server chose to fallback to a full-handshake directly in the same
way, that the server would do, if no matching session id is available.

https://datatracker.ietf.org/doc/html/rfc5246#page-36

"The client sends a ClientHello using the Session ID of the session to
be resumed.  The server then checks its session cache for a match.
...
If a Session ID match is not
found, the server generates a new session ID, and the TLS client and
server perform a full handshake."

With such a fallback by the server, the general rule, to only use
"full-handshakes", will be also full filled. And the benefit would be,
that the client doesn't need to send a second handshake.

best regards
Achim Kraus

Am 28.10.21 um 19:44 schrieb David Benjamin:
> It depends on what the server is trying to do. If the server is trying
> to mandate EMS, aborting the connection is correct. E.g. the full
> handshake section then says:
>
> Though I suppose the abbreviated handshake version is missing a "if it
> does not wish to interoperate with legacy clients". Yeah, okay, this
> probably also needs an erratum to add the right qualifier. Gosh this
> document is confusingly organized.
>