I think we're overstating the "otherwise" case. A client that uses this
strict 4507 format would initially send a ticket that looks like { 00 23
00 02 00 00 } to which our server would reject this extension (since the
final 00 00 would be interpreted as a ticket when the client did not
intend it to be so). The result of this SHOULD be that the server
responds with a ServerHello that doesn't have the SessionTicket extension.
That doesn't mean that resumption cannot happen. It just means that
resumption happens using the usual session ID lookup approach and the
server is caching the session rather than letting the client do the
work. Given that this is a degenerate case for what (I hope) is a small
subset of older clients, I think using server-cached sessions is OK.
I don't believe we should ever find ourselves in a case where the
strict-4507 client actually gets a real ticket from our server, and in
turn should never hand us a ticket thinking that resumption could
actually take place via said ticket.
On the client side, we cannot know ahead of time that the server is
strict-4057, so we have to send a 5077 style SessionTicket extension.
The server will probably not like that and not assert SessionTicket in
its server hello. So our client should fall back to using the session
ID to support resumption, and the server should follow suit by caching
the session.
--Jamil
On 6/5/2019 2:28 PM, Xuelei Fan wrote:
I don’t know if there are any deployment of RFC 4507. If not, we are safe;
otherwise there are interop problems for session resumption.
Xuelei
On Jun 5, 2019, at 2:19 PM, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote:
Hi Xuelei,
Given that 4507 is obsoleted in favor of 5077 is there really that much value
to supporting this older/broken extension format? Do we know of clients that
still adhere to 4507? Otherwise it seems better to stick to 5077 and the
approach in TLS 1.3 and not try to go back and support an earlier obsoleted
approach to this feature.
These lines took me to the cooperation behaviors between RFC 5077 and RFC 4507.
It looks like we don't support RFC 4507 format of SessionTicket extension. As
RFC 5077 and RFC 4507 use the same extension ID for different extension format.
There are potential compatibility issues, and make session resumption
impossible. I would like to have a workaround to accept both formats. For
example, using the a cookie at the beginning of the ticket, as described in
appendix-A of RFC 5077.
I will review the rest of this class in the afternoon or tomorrow.
Thanks,
Xuelei
