[External] : Re: Request for comment: the session ticket protection scheme for distributed TLS sessions.

[Xuelei Fan]

Thank you Daniel for the comment.  All are great points.

> On Mar 17, 2021, at 1:56 AM, Daniel Jeliński <djelinski1 at 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.FAN at 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.Fan at 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>
>>