Request for comment: the session ticket protection scheme for distributed TLS sessions.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Request for comment: the session ticket protection scheme for distributed TLS sessions.

Xue-Lei Fan
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 (631K) Download Attachment
doc_distributed_credential_protection.md (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Xue-Lei Fan
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 <[hidden email]> 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>


distributed_credential_protection.pdf (127K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Daniel Jeliński
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.

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.

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?

I didn't find answers in the JEP or in the CSR, so I thought I'd ask here.
Thanks,
Daniel

[1] https://tools.ietf.org/html/rfc8446#appendix-E.1

czw., 29 paź 2020 o 04:41 Xue-Lei Fan <[hidden email]> 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 <[hidden email]> 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>
>
Reply | Threaded
Open this post in threaded view
|

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

Xue-Lei Fan
Thank you Daniel for the comment.  All are great points.

> On Mar 17, 2021, at 1:56 AM, Daniel Jeliński <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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>
>>