[TLS] comments & clarifications for rfc4507bis

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

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;


S4:
      enum {
         anonymous(0),
         certificate_based(1),
         psk(2),
+       (255)
     } ClientAuthenticationType;

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.
>
> 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.)
>
> 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.
>
> Thanks,
> nagendra
>

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