RFR 8211018: Session Resumption without Server-Side State

[Xuelei Fan]

;-) I want to try again by putting all things together.

Per RFC 5077 (page 18, appendix A):
   "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
   "

I think we all agreed that a RFC 4507 client could use either format. 
So here comes two cases:

Case 1:
-------
If a RFC 4507 client use the format for the empty SessionTicket extension:
         00 23      Extension type 35
         00 02      Length of extension contents
         00 00      Length of ticket

A RFC 5077 server could reject or ignore the extension as it cannot 
recognized the format (I did not read this part of impl yet, I don't 
know if the connect is terminated/rejected or just ignore the 
extension).  Then the stateless mechanism is not used.  It's fine to me 
if the extension is ignored.

Case 2:
-------
If a RFC 4507 client use the format for the empty SessionTicket extension:
         00 23      Extension type 35
         00 00      Length of extension contents

A RFC 5077 server don't know if the client is RFC 4507 or RFC 5077. The 
RFC 5077 server go with stateless and response with an empty ST in SH.
        00 23      Extension type 35
        00 00      Length of extension contents

And the client could accept the empty ST in SH.  And the server send a 
NST message, and the client could parse it as well.

The RFC 4507 client uses the following format for session resumption:
        00 23          Ticket Extension type 35
        01 02          Length of extension contents
        01 00          Length of ticket
        FF FF .. ..    Actual ticket

If the RFC 5077 server cannot parse it, the session resumption cannot be 
performed, and fall-back to full-handshake.  That's the concern of mine.

Xuelei

On 6/5/2019 9:44 PM, Xuelei Fan wrote:
> On 6/5/2019 8:25 PM, Anthony Scarpino wrote:
>> On 6/5/19 7:30 PM, Xuelei Fan wrote:
>>> On 6/5/2019 7:21 PM, Anthony Scarpino wrote:
>>>>
>>>>> On Jun 5, 2019, at 5:37 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>>>
>>>>>> On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
>>>>>> 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.
>>>>> Hm, I agreed with you.
>>>>>
>>>>>> 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 may view it differently.
>>>>>
>>>>> If an implementation encoded per the format:
>>>>>          00 23      Extension type 35
>>>>>          00 02      Length of extension contents
>>>>>          00 00      Length of ticket
>>>>>
>>>>> Just as your analysis previous, a RFC 5077 server will just ignore 
>>>>> the extension.  No real hurt actually.
>>>>>
>>>>> But if an implementation encoded empty SessionTicket extension per 
>>>>> the format (the known implementation):
>>>>>          00 23      Extension type 35
>>>>>          00 00      Length of extension contents
>>>>>
>>>>> The server could read it as RFC 5077, and use stateless 
>>>>> implementation. When the ServerHello extension sent back.  No 
>>>>> matter the RFC 4057 client accept it or not, there are interop issues.
>>>>>
>>>>> If the client does not accept it (unlikely), the connection cannot 
>>>>> be established.
>>>>>
>>>>> If the client accept it, the resumption session will use the 
>>>>> negotiated ticket, and then non-empty SessionTicket extension is 
>>>>> encoded as:
>>>>>         00 23          Ticket Extension type 35
>>>>>         01 02          Length of extension contents
>>>>>         01 00          Length of ticket
>>>>>         FF FF .. ..    Actual ticket
>>>>>
>>>>> The server would have to handle it (RFC 4507 format) if it want the 
>>>>> session resumption works.  Here come the interop issues.
>>>>>
>>>>
>>>> That is true, but i believe it is extremely unlikely that the length 
>>>> would not be in the ST empty extension, but the length would be in 
>>>> the ST resumption extension.
>>>>
>>> I did not get the point.
>>>
>>
>> The below two messages I believe are even less likely to occur.  4 
>> byte ST message ([Ext Type, Ext Len]) with a 6 byte NST message ([Ext 
>> Type, Ext Len, Ticket Len] + Actual ticket) would mean the 
>> implementation was coded up correctly for the ST and incorrectly the NST.
>>
>>> If I read the appendix A of RFC 5077 correctly, the initial handshake 
>>> uses (for known implementation, which is the ambiguous part of RFC 
>>> 4507):
>>>          00 23      Extension type 35
>>>          00 00      Length of extension contents
>>
>> Yes, this is 5077, and if 4507 was properly implemented if I 
>> understand the appendix right.  But 4507 may also include the length 
>> of the ticket as well as the length of the extension, like you 
>> mentioned in the early message.
>>
> I agreed.  Both RFC 4507 and RFC 5077 use the above format.  And RFC 
> 4507 could use another format as well.
> 
>>> And session resumption uses (which is not ambiguous for RFC 4507):
>>>          00 23          Ticket Extension type 35
>>>          01 02          Length of extension contents
>>>          01 00          Length of ticket
>>>          FF FF .. ..    Actual ticket
>>>
>>> So it is the known format/behavior if RFC 5077 is right.
>>
>> This is not a valid ticket for 5077,
> No, it is not.  It is the format of RFC 4507.  The problem comes because 
> it is not a valid ticket for 5077.  If it is valid format for RFC 5077, 
> there is no problem, I guess.
> 
> Let me try again.
> 
> RFC 4507 client uses the following format for the initial handshake:
>         00 23      Extension type 35
>         00 00      Length of extension contents
> 
> The RFC 5077 server response with an empty ST in SH.
>         00 23      Extension type 35
>         00 00      Length of extension contents
> 
> The client could accept the empty ST in SH.
> 
> The server send a NST message, and the client could parse it as well.
> 
> The RFC 4507 client uses the following format for session resumption:
>         00 23          Ticket Extension type 35
>         01 02          Length of extension contents
>         01 00          Length of ticket
>         FF FF .. ..    Actual ticket
> 
> If the RFC 5077 server cannot parse it, it is not possible for session 
> resumption, fall-back to full-handshake.
> 
> I think it will always happen as if the client complies to RFC 4507.
> 
>> this is the confusion of 4507.  It cannot be interpreted as 5077 
>> because the ticket length will leak into the actual ticket and corrupt 
>> the crypto.
> Sure, it is not a RFC 5077 format so it cannot be parsed as RFC 5077. 
> That's the problem that the appendix A of RFC 5077 is trying to 
> describe, I think.
> 
> Xuelei
> 
>>   When the crypto fails the code will not proceed with resumption, 
>> going into full handshake.
>>
>> Tony