I suspect we are using "symmetric" in different sense. I tried to search for it in RFC8446bis but out of the 10 occurrences, none seem relevant to negotiation.
On 17.07.25 11:38, Eric Rescorla wrote:
At least from my side, it is too early to declare it disagreement. I am still trying to understand your proposal to try it out in the formal model.On Wed, Jul 16, 2025 at 10:32 PM Muhammad Usama Sardar <[email protected]> wrote:Right. However, the actual data is in CERT.Correct, but just to clarify, my point was that in both cases (Client as Attester and Server as Attester), the negotiation is symmetric and ends in EE. So I don't see any asymmetry from negotiation perspective. As I understood, your main point was about asymmetry in negotiation. I think we'll have to agree to disagree here:
in the Client as attester the client announces what it can do and the server tells it what it wants.
I fully agree with this. The former in CH and the latter in EE.
In Server as attester the client says what it wants and the server tells it what it will do.
I fully agree with this. The former in CH and the latter in EE.I see it symmetric in the above sense and also in time perspective that in both cases, negotiations finish by the time handshake reaches the EE message.
That's unnecessarily inconsistent.
Do I understand correctly that your proposal is that for Client as Attester, Server could use CertificateRequest message (instead of EncryptedExtensions) to indicate which format it will use for Evidence. I don't yet see in which sense it will make it "consistent".
More importantly, do you think there could be some attacks or is your proposal just for consistency/alignment?
Usama [1] https://mailarchive.ietf.org/arch/msg/tls/8lULn0tfC-Jm9aPXtBiYUpgKVt4/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
