Subject: [TLS] comments & clarifications for rfc4507bis

From: "Nagendra Modadugu" <[email-masked]>
Date: Wed, 3 Oct 2007 15:43:02 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Nagendra Modadugu" <[email-masked]>
Date: Thu, 4 Oct 2007 13:21:46 -0700

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;

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Oct 2007 15:23:32 -0700

Hi Nagendra,

Thanks for reviewing the draft and providing comments:

Comments inline below: 

> -----Original Message-----
> From: Nagendra Modadugu [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 1:22 PM
> To: [email-masked]
> Subject: [TLS] comments & clarifications for rfc4507bis
> 
> A few more comments:
> 
> 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 {
[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.  

>      } ClientAuthenticationType;
[Joe] OK, thanks, more below

> > received (by the client) until application data is received 
[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."  

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

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

---

From: "Nagendra Modadugu" <[email-masked]>
Date: Fri, 5 Oct 2007 16:47:57 -0700

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

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

> 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

---

From: "Nagendra Modadugu" <[email-masked]>
Date: Mon, 8 Oct 2007 15:15:22 -0700

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 11 Oct 2007 17:45:53 -0700

Hi Nagendra,

Comments inline below: 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Nagendra Modadugu
> Sent: Friday, October 05, 2007 4:48 PM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [TLS] comments & clarifications for rfc4507bis
> 
> > > It could either mean the entire NewSessionTicket message, or just 
> 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. "

> 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 
> Simultaneously supporting stateful and stateless resumption 
> leads to some tricky situations which the draft does not 
> address.  Consider the following situation:
> 
>   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
>   has a cache hit on SID1 and also finds that ST2 is valid.  
> Which session does the server
> 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.  "

> (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 
> '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 
[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.

---

From: Mike <[email-masked]>
Date: Thu, 11 Oct 2007 21:26:57 -0700

>>>> The description would be unabiguous if 
>> I'm afraid that l/
or server operators don't understand this stuff to the level
required to make all the right choices.

>> Another issue I've been meaning to bring up is that
>> if you want forward secrecy, you need to use Diffie-
>> Hellman; however, there is no way to tell the server
>> the size of the parameter p you want.  Increasing the
>> size of p has significant performance implications,
>> so servers will typically use 1024 bits.
>> [...] It would be better if those
>> who want to use 4096 bits could ask for it.
> 
> Again, please present some evidence that this is a real
> practical issue outside of a very small population of 
> keylength fetishists.

RSA key exchange provides up to 368 bits of security, but
doesn't provide forward secrecy.  If I want forward secrecy,
then I need to use Diffie-Hellman.  A server that has 1024-
bit Diffie-Hellman parameters only provides me with some-
where in the neighborhood of 70-80 bits of security
(extrapolated from the data in RFC 3526).  You are saying
that I am a "keylength fetishist" because I want better
than 70-80 bits of security?  So I'm allowed either lots
of "strength" *or* forward secrecy, but not both?  That's
irresponsible.

Mike

---

From: Mike <[email-masked]>
Date: Thu, 11 Oct 2007 21:26:57 -0700

> to remove this ambiguity.

How about:

   struct {
       opaque NewSessionTicket.ticket[NewSessionTicket.ticket.length];
   } SessionTicket;

Not perfect, but better than nothing.  I too was looking for a struct
to define the extension data....

Mike

eaving this portion of the description in 
> to remove this ambiguity.

How about:

   struct {
       opaque NewSessionTicket.ticket[NewSessionTicket.ticket.length];
   } SessionTicket;

Not perfect, but better than nothing.  I too was looking for a struct
to define the extension data....

Mike