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

[Achim Kraus <[e-mail]>]

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:
> 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. :-)
>
> Now, as to your question, I don't believe this is right:
>
>  > 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.
>
> 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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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/
>     <https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/>
>
>     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
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> 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.
>      >
>      > https://datatracker.ietf.org/doc/html/rfc7627#section-5.4
>     <https://datatracker.ietf.org/doc/html/rfc7627#section-5.4>
>      >     <https://datatracker.ietf.org/doc/html/rfc7627#section-5.4
>     <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
>      >
>      >
>      > _______________________________________________
>      > TLS mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>      >
>