Thank you Daniel for the comment. All are great points. > On Mar 17, 2021, at 1:56 AM, Daniel Jeliński <djelins...@gmail.com> wrote: > > Hi Xuelei, > I reviewed the RFC above (I hope I'm not too late!) and have some > concerns about the security properties of the proposed solution. > Essentially they would apply to all schemes using session ticket > encryption keys derived from a long-lived secret. >
I understand the concerns completely. It is really a compromising solution so as to simplify the TLS session distribution problems. > How does this apply to TLS versions before 1.3? My understanding is > that deriving session ticket encryption keys from a long-term secret > immediately forfeits all forward secrecy in all versions of TLS before > 1.3. This also applies to TLS 1.3 when psk_ke is used. > Unfortunately, there is no forward secrecy benefits for TLS 1.2 and psk_ke for TLS 1.3. For TLS 1.2 and psk_ke, new distributed keying materials should be introduced for forward secrecy benefits. I will consider an improvement here. > How are we going to ensure Key Compromise Impersonation (KCI) > resistance (defined in [1])? Will it be possible for an attacker to > spoof peer certificates in a session ticket if he gains access to our > long-term secret? > Sorry for the delayed response. It took me a while to understand the impact of KCI. As far as I could understand, the KCI resistance is at the same level as the one-client-one-server mode connections, if we design and validate the session ticket carefully. > I didn't find answers in the JEP or in the CSR, so I thought I'd ask here. Thank you for the comments, which definitely help me a lot. Xuelei > Thanks, > Daniel > > [1] > https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8446*appendix-E.1__;Iw!!GqivPVa7Brio!Jn80lostzwxXdApD87mhqhgrhjD3mUdQL6a_wTCxBdBZrJXI5OiS-q8mRQi4EltR$ > > > czw., 29 paź 2020 o 04:41 Xue-Lei Fan <xuelei....@oracle.com> napisał(a): >> >> The PNG may be too large to open from some mail system. Here is the PDF >> version. BTW, I also made an update on the use of AEAD algorithm with >> additional data. >> >> Thanks, >> Xuelei >> >> >>> On Oct 23, 2020, at 8:58 AM, Xuelei Fan <xuelei....@oracle.com> wrote: >>> >>> Hi, >>> >>> I'm working on the JEP to improve the scalability and throughput of the TLS >>> implementation, by supporting distributed session resumption across >>> clusters of computers. >>> >>> TLS session tickets will used for session resumption in a cluster. To >>> support distributed session resumption, a session ticket that is generated >>> and protected in one server node must be usable for session resumption on >>> other server nodes in the distributed system. Each node should use the same >>> session ticket structure, and share the secrets that are used to protect >>> session tickets. More details, please refer to the JEP: >>> https://bugs.openjdk.java.net/browse/JDK-8245551 >>> >>> It is a essential part of the implementation that we need to define a >>> session ticket protection scheme. The scheme will support key generation, >>> key rotation and key synchronization across clusters of computers. >>> >>> The attached doc_distributed_credential_protection.md is a markdown file, >>> which may not easy to read. So I attached a rendered picture as well. >>> >>> Please let me know if you have any concerns. Any comments are welcome. >>> >>> Thanks, >>> Xuelei >>> <distributed-credentials.png><doc_distributed_credential_protection.md> >>
