[TLS] Re: comments & clarifications for rfc4507bis

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

One more comment:

S3.3: The value indicates the lifetime in seconds as a 32-bit unsigned
integer in network
     byte order.

Is 'lifetime' relative (e.g. 10 hours = 10 * 3600) or absolute, e.g.
in seconds since UTC?  It would make sense that
NewSessionTicket.ticket_lifetime_hint is relative (to avoid the
effects of clock-skew between the server and client.)  The text would
be clearer if it were explicit about the meaning of 'lifetime'.

On 10/4/07, Nagendra Modadugu <[e-mail]> wrote:
> 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