RFR[13] Release Note for Stateless Resumption

Xuelei Fan xuelei.fan at oracle.com
Mon Jul 8 18:16:13 UTC 2019

On 7/8/2019 10:40 AM, Anthony Scarpino wrote:
> On 7/8/19 10:00 AM, Xuelei Fan wrote:
>> On 7/8/2019 9:06 AM, Anthony Scarpino wrote:
>>> On 7/8/19 8:30 AM, Xuelei Fan wrote:
>>>> Hi,
>>>> A couple of comments.
>>>> In the release note, "For TLS 1.3, stateless tickets use the 
>>>> existing PSK resumption extension in RFC 8446[2]. TLS 1.3 will 
>>>> revert to the session cache if the server property is false. "
>>>> In CSR, "For TLS 1.3, stateless tickets use the existing PSK 
>>>> resumption extension in (RFC 8446), which require no properties or 
>>>> settings."
>>>> The above two parts of information are not consistent.
>>> Correct, however, while 1.3 uses the existing ticekt mechanism for 
>>> stateless and stateful without a property setting.  However the 
>>> contents of that ticket do depend on the property.
>> I think for TLS 1.3, the contents of the ticket should be independent 
>> from the property.  The property names 
>> "jdk.tls.server.enableSessionTicketExtension" and 
>> "jdk.tls.client.enableSessionTicketExtension" are about the ST 
>> extension.  TLS 1.3 session resumption uses a different mechanism.
>> I may missed something.  Why you think the content of the ticket 
>> depending on the property?
>> Thanks,
>> Xuelei
> How else is the context going to be controlled?  Otherwise 1.3 will 
> always be stateless
I think we are not on the same page about the bound values in another 
code review thread, which could be related to this topic.  We can talk 
about this point later when we have an agreement there.

> and the SSLSessions will always lack information 
> that some may want.
I may missed something more.  I don't think SSLSessions can lack 
information even for stateless.

> While the property name isn't entirely accurate, the result is the same 
> for 1.2 and 1.3.  I thought this was the compromise we came up with when 
> I had 4 properties and you wanted less.
Sorry, I thought we had an agreement that TLS 1.3 is independent from 
the property.


More information about the security-dev mailing list