RE: [TLS] comments & clarifications for rfc4507bis

["Joseph Salowey (jsalowey)" <[e-mail]>]

Hi Nagendra,

Comments inline below: 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> Nagendra Modadugu
> Sent: Friday, October 05, 2007 4:48 PM
> To: Joseph Salowey (jsalowey)
> Cc: [e-mail]
> Subject: Re: [TLS] comments & clarifications for rfc4507bis
> 
> On 10/5/07, Joseph Salowey (jsalowey) <[e-mail]> wrote:
> > Hi Nagendra,
> >
> > Thanks for reviewing the draft and providing comments:
> >
> > Comments inline below:
> >
> > > -----Original Message-----
> > > From: Nagendra Modadugu [mailto:[e-mail]]
> > > Sent: Thursday, October 04, 2007 1:22 PM
> > > To: [e-mail]
> > > Subject: [TLS] comments & clarifications for rfc4507bis
> > >
> > > A few more comments:
> > >
> > > S3.1: The client caches this ticket along with the master 
> secret and
> > >       other parameters associated with the current session.
> > > When the client
> > >       wishes to resume the session, it includes the ticket in the
> > >       SessionTicket extension within the ClientHello message.
> > >
> > > The text is not clear what "includes the ticket" refers to.
> > > It could either mean the entire NewSessionTicket message, or just 
> > > NewSessionTicket.ticket.  The client does not need to echo back 
> > > NewSessionTicket.ticket_lifetime_hint, so it is not 
> obvious which of 
> > > the two meanings is implied.  The description would be 
> unabiguous if 
> > > the text included a struct along the lines of:
> > >
> > >   struct {
> > >     opaque NewSessionTicket.ticket<1..2^16-1>
> > >   } SessionTicket;
> > >
> > >
> > [Joe] I would rather clarify this by saying:
> >
> >  "When the client wishes to resume the session, it includes 
> the ticket 
> > contained within the NewSessionTicket message, in the SessionTicket 
> > extension within the ClientHello message. "
> >
> > The new struct actually reintroduces an issue with encoding that we 
> > trying to correct with this revision.
> >
> 
> The text (even the correction you suggest) is not unambiguous 
> about what the 'the ticket' constitutes.  Is it a length 
> encoded vector NewSessionTicket.ticket or the serialized 
> structure embedded within?
> I'm not familiar with what the previous draft specified, but 
> I assume you mean the latter.  Could you clarify?
> 
> I'm afraid that leaving this portion of the description in 
> textual form may lead to implementation bugs -- it would be 
> nice to see a struct.
> 
[Joe] It is the serialized ticket without the length encoding that would
be introduced by the struct encoding.  The text has been modified to try
to remove this ambiguity.  Would the following text help:

"When the client wishes to resume the session, it includes the
serialized ticket contained within the NewSessionTicket message, in the
SessionTicket extension within the ClientHello message.  Appendix A
provides a detailed description of the encoding of the extension and
changes from RFC 4507. "

> >
> > > On 10/3/07, Nagendra Modadugu <[e-mail]> wrote:
> > > > Apologies if the points below have been previously 
> addressed.  The 
> > > > comments below are in reference to the version of the 
> draft dated 
> > > > S3.4: If a server is planning on issuing a 
> SessionTicket to a client
> > > >       that does not present one, it SHOULD include an empty
> > > Session ID in the
> > > >       ServerHello.  If the server includes a non-empty
> > > session ID, then it
> > > >       is indicating intent to use stateful session resume.
> > > If the client
> > > >       receives a SessionTicket from the server, then it 
> discards any
> > > >       Session ID that was sent in the ServerHello.
> > > >
> > > > Why are servers afforded the flexibility of simultaneously
> > > including
> > > > an extension and session ID?  Or differently put, why
> > > should a server
> > > > ever need to generate a session ID if it intends to do
> > > stateless resumes?
> > > > (Session IDs generated by the server will be discarded by
> > > the client
> > > > in any case.)
> > > >
> > [Joe] During discussions for RFC 4507 there was a desire to allow 
> > stateful resume during fallback to a full handshake.
> >
> 
> If this is the case then "it [server] SHOULD include an empty 
> Session ID in the ServerHello" and "client ignores the 
> Session ID sent in the ServerHello" are confusing.  If the 
> draft is recommending (for or) against simultaneously 
> supporting stateful and stateless resumption, it should say 
> so explicitly (noting that a server should be aware that 
> clients supporting stateless resumption might not attempt stateful
> resumption.)
> 
> Simultaneously supporting stateful and stateless resumption 
> leads to some tricky situations which the draft does not 
> address.  Consider the following situation:
> 
>   Client C makes a TLS connection T1 to server S and receives 
> session-ID SID1 and
>   SessionTicket ST1.  The client does another full handshake 
> and receives SID2 and ST2.
>   Now C makes a third connection to S, but this time 
> attempting to resume, including session ID
>   SID1 and SessionTicket ST2 (note this is the second SessionTicket
> received.)  The server
>   has a cache hit on SID1 and also finds that ST2 is valid.  
> Which session does the server
>   pick?  What should the client infer about the server's choice?
> 
> I'd like to add that this situation is not esoteric.  A 
> client implementation may have two hash tables (one of 
> session IDs and other of SessionTickets.)  It's pretty easy 
> to end up mixing and matching.
> 
[Joe] OK, thanks I think I see the confusion.  The desired behavior is
for the server to fall back to a full handshake if it does not accept
the ticket.  The client cannot simultaneously request both stateful and
stateless resumption, stateless resumption takes precedence.  When the
server responds with the server hello in the case of a full handshake it
can provide a session ID for stateful resume.  I think the text does
state this, however the first paragraph is a bit confusing and
potentially conflicts with the second paragraph:

  "If a server is planning on issuing a SessionTicket to a client that
   does not present one, it SHOULD include an empty Session ID in the
   ServerHello.  If the server rejects the ticket and falls back to the 
   full handshake then it may include a non-empty Session ID to indicate
   its support for stateful resume.  If the client receives a 
   SessionTicket from the server, then it discards any Session ID that 
   was sent in the ServerHello.  "

> > > > S3.4: In this case, the client ignores the Session ID sent in
> > > >       the ServerHello ...
> > > >
> > > > "the Session ID" -> "the Session ID (whether empty or 
> non-empty)"
> > > >
> > > > S3.4: If the server accepts the ticket and the Session ID
> > > is not empty,
> > > >       then it MUST respond with the same Session ID 
> present in the
> > > >       ClientHello.  This allows the client to easily
> > > differentiate when
> > > >       the server is resuming a session from when it is
> > > falling back to a
> > > >       full handshake.
> > > >
> > > > What if the server rejects the ticket in this case?  It seems 
> > > > reasonable that the server responds with an empty session ID to 
> > > > indicate to the client that a full-handshake is being initiated.
> > > >
> > [Joe] If the server rejects the ticket and it is planning 
> on issuing a 
> > new ticket then it SHOULD include an empty session ID.  If 
> the server
> 
> This text does not preclude a server from (a) rejecting the ticket and
> (b) echoing the session ID sent by the client.  Doing (b) is 
> confusing for the client for the reasons described in the 
> example above -- how does the client tell that the server has 
> reject the ticket, but is instead doing a stateful resume 
> (where the session ID and ticket refer to different 
> sessions)?  This problem could be addressed by saying 
> something along the lines of:
> 
> 'If a client receives a session ID along with a session 
> ticket from a server, the client infers that the server 
> supports both stateless and stateful resumption.  Clients 
> attempting stateless resumes SHOULD send empty session IDs.  
> If a client attempting a stateless resume includes a session 
> ID, then the session ID MUST be the same session ID that was 
> issued along with the session ticket."
> 
[Joe] I think the changes above in the first paragraph, above, clarifies
the issue along with the line in the second paragraph that states 

"If a ticket is
   presented by the client, the server MUST NOT attempt to use the
   Session ID in the ClientHello for stateful session resume."

If the client presents a ticket then the server must ignore the Session
ID and not perform stateful session resume.

> Thanks,
> nagendra
> 


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls