RFR 8211018: Session Resumption without Server-Side State

[Xuelei Fan]

On 6/5/2019 3:37 PM, Jamil Nimeh wrote:
> 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.
> 
I'm not very sure if I read the Appendix A of RFC 5077 correctly. I 
think it is trying to explain that client does not use strict-4507 for 
the empty extension and then result in the interop issues.

Page 18, RFC 5077:
"   Note that the encoding of an empty SessionTicket extension was
    ambiguous in RFC 4507.  An RFC 4507 implementation may have encoded
    it as:

         00 23      Extension type 35
         00 02      Length of extension contents
         00 00      Length of ticket

    or it may have encoded it the same way as this update:

         00 23      Extension type 35
         00 00      Length of extension contents
"

> 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.
> 
I agreed.  We should stick to the RFC 5077 format in client side.

Thanks,
Xuelei

> --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.nimeh at 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
>>>
>>>
>>>
>>>
>>>
>