RFR 8211018: Session Resumption without Server-Side State

[Jamil Nimeh]

I think what it's saying is that what was explicitly called out in 4507 
(where there is both the extension_data length bytes AND the opaque 
vector length) is not how deployed implementations did it. It implies 
that deployed implementations do what you laid out below where you just 
have 2 bytes of ID and 2 bytes of length.  And I believe that is 
compatible with what 5077 specifies.

So the potential problem is if one endpoint or the other happens to 
implement 4507 to the letter, extra length bytes and all.  But the 
authors of 5077 say that no known implementations do this.  That's good 
for us I think, because in the two-ish years between 4507 and 5077 
nobody did straight 4507, or they maybe did and fixed it by the time 
5077 came around.

I dug up a few pcaps I've kept around during testing of other TLS 
features over the past few years.  I had Chrome, Mozilla and OpenSSL 
s_client pcaps and they all appear to follow the 5077 format.  Of 
course, anything after 2008 is more likely to do 5077 than 4507.

--Jamil

On 6/5/2019 4:35 PM, Xuelei Fan wrote:
> I'm not sure I understand the following words in page 17, RFC 5077.
>
> "  An error in the encoding caused the specification to differ from
>    deployed implementations.  At the time of this writing there are no
>    known implementations that follow the encoding specified in RFC 4507.
> "
>
> Is it means that the known implementation encode empty SessionTicket 
> extension as?
>         00 23      Extension type 35
>         00 00      Length of extension contents
>
> Xuelei
>
> On 6/5/2019 4:26 PM, Xuelei Fan wrote:
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>