RE: [TLS] comments & clarifications for rfc4507bis

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

Hi Nagendra,

Thanks for reviewing the draft and providing comments:

Comments inline below: 

> -----Original Message-----
> From: Nagendra Modadugu [mailto:ngm+ietf at google.com] 
> Sent: Thursday, October 04, 2007 1:22 PM
> To: tls at ietf.org
> 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.  

> S4:
>       enum {
>          anonymous(0),
>          certificate_based(1),
>          psk(2),
> +       (255)
>      } ClientAuthenticationType;
> 
[Joe] OK, thanks, more below

> On 10/3/07, Nagendra Modadugu <ngm+ietf at google.com> 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.    

> > 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
rejects the ticket and does not plan to issue a new ticket then it MUST
either include a different session ID or an empty session ID.  A
non-empty session ID allows for stateful session resume.  

> > Thanks,
> > nagendra
> >
> 
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls