RFR[13] Release Note for Stateless Resumption

[Anthony Scarpino]

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 and the SSLSessions will always lack information 
that some may want.

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.

Tony