On 30.01.26 09:50, Aijun Wang wrote:
Well, I *NEVER* endorsed it to be done at TLS layer. As I said clearly, you have to defend that yourself. I shared some preliminary working that -- I hope -- will help you move forward. Until I say *explicitly* that I have evaluated both options, please don't take anything for granted.Thanks for your endorsement to implement it at TLS layer.
While the idea may be straightforward for you, the draft is unfortunately not straightforward for me. There is no clear description of problem statement, motivation, threat model and desired security goals. I requested you to add authentic references in the draft but I don't see any change. As far as the protocol diagram is concerned, I have requested you at least 3 times to move the protocol to TLS 1.3 but nothing has changed in the draft.As your suggestion, if TLS 1.3 has no explicit session identifier, we can utilize the implicit one, for example, PSK, as the identification of the corresponding session.The idea of this draft is actually very straightforward: 1) Notify the client securely another address2) Start one new TLS session which can utilize the PSK of the previous session(then skip the negotiation process for the new session).3) Keep the application unnoticed, or application agnostic.
Without these requested inputs, I am unable to help you any further. Sorry! -Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
