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