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 <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>
>

Reply via email to