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