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
