Re: [TLS] comments & clarifications for rfc4507bis

["Nagendra Modadugu" <[e-mail]>]

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.

> > S4:
> >       enum {
> >          anonymous(0),
> >          certificate_based(1),
> >          psk(2),
> > +       (255)
> >      } ClientAuthenticationType;
> >
> [Joe] OK, thanks, more below
>
> > 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
> > > August 27, 2007.
> > >
> > > S3.3: The server MUST NOT assume that the client actually
> > received the updated
> > >       ticket until it successfully verifies the client's Finished
> > >       message.
> > >
> > > This text seems incorrect.  The full-handshake case is
> > actually a bit
> > > awkward, since the server cannot assume that the ticket has been
> > > received (by the client) until application data is received
> > from the client.
> > >
> [Joe] Ah, I see your point, the client sends its finished message before
> it receives the ticket. We should probably change this to
>
> "The server MUST NOT assume that the client actually received the
> updated ticket until it successfully receives application data from the
> client."
>
> > > 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.

> > > 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."

Thanks,
nagendra

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