Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt

From: [email-masked]
Date: Tue, 27 Sep 2005 17:00:38 +0300

Nelson B. Bolyard wrote:

> 2. I think there needs to be a clear set of rules regarding the
> use of SessionIDs with SessionTickets.  Otherwise, clients and
> servers are likely to make different assumptions about what is
> and is not permissible and be non-interoperable as a result.  I
> think the document should answer these questions:
> 
> Q1) When the server establishes a new session, and intends to
> send a new SessionTicket to the client for subsequent session
> resumption,
> 
> Q1A) Is it permissible to send an empty (zero length) SessionID
> in the server_hello, and have the session (in the ticket) still
> be resumable?
> 
> Q1B) Is it permissible for the server to use the same non-empty
> SessionID for many different sessions (given that the real
> session info is in the ticket, not in a cache)?
> 
> Q2) When the client receives a SessionTicket from a server, and
> attempts to resume that session in a subsequent handshake with
> a SessionTicket extension to the client_hello, must it send in
> the client_hello the same SessionID value that it previously
> received in the server_hello (even if it was empty)?
> 
> Or, does the ticket extension completely override the SessionID?
> Could the client ignore the received SessionID and instead send a
> client_hello with a zero-length SessionID and the ticket extension,
> and still rightfully expect that the session would be resumed?

My proposal would be that SessionID is used as before (this
should minimize changes to client implementations). In other words,

- When a new session is established, and the server intends
  to send a new SessionTicket, it also sends a non-empty SessionID.
- When the client attempts to resume a session using a ticket, 
  it also sends the normal (non-empty) SessionID value.
- If the server does not wish to resume a session, it starts 
  a full handshake (and replies with a different Session ID)
  as usual

Suggested text: change 
  
   "When the client wishes to resume the session, it includes a
   SessionTicket TLS extension in the SessionTicket extension within
   ClientHello message."

to
  
   "When the client wishes to resume the session, it includes the
   SessionID and a SessionTicket TLS extension containing the
   actual ticket in the ClientHello message."

And add "The server MUST also send a non-empty SessionID in
ServerHello to indicate this session can be resumed." to the
end of the 2nd paragraph of Section 3.1.

> Q3) If clients must preserve the pairing of SessionID and ticket,
> must servers enforce that, either by (a) sending an alert if not
> matched or (b) starting a new session when mismatch occurs?
> 
> The answers to those questions have implications on how the clients
> would implement their session caches, and on what rules servers should
> enforce regarding mismatches of received SessionIDs and tickets.

If the server for some reason doesn't wish to resume a session,
it should just start a new one.

> 3. Regarding the Sample Ticket Construction, a few suggestions
> based on the belief that many implementors will follow it to
> the letter, as if it were a specification.
> 
> a) Implementors will use the key_version as a key number.  A
> 32-bit value will limit the space.  I suggest making it larger,
> e.g. an opaque of 16 or more bytes, with strong advice that
> this is NOT the place to store the key itself.  :)

I think most implementations will store only two keys ("current"
and "previous"); in that case, a 1-bit field would be enough.
In what situation would a 32-bit value be too small?

> b) Similarly, I suggest putting a field at the front of the
> ExampleStatePlaintext to contain a large random value, to thwart
> known plaintext attacks on its contents.

If the cipher is so seriously broken that you could realistically
break it, using it for this extension will be insecure no matter what.

> c) In the interest of efficiency, I suggest that the MAC in
> ExampleTicket should include the complete encoded contents of the
> fields that preceed it in the ExampleTicket, including the encoded
> length(s).  That will allow the MAC to be computed with just a
> single input, without having to copy data to eliminate the
> length(s).

Agreed. Suggest changing the text to:

   "The MAC is calculated using HMAC-SHA1 over key_version (4 octets)
   and IV (16 octets), followed by the length of the encrypted_state
   field (2 octets) and its contents (variable length)."

Best regards,
Pasi

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 29 Sep 2005 15:45:55 -0700

Hi Nelson,

Thanks for the review comments inline below: 

> 1. Structs SessionTicket and NewSessionTicket are duplicates. 
>  I suggest eliminating NewSessionTicket and using struct 
> SessionTicket every place where NewSessionTicket is now used 
> in the document.
> 
> I'm suggesting that the new message be defined as
>               case new_session_ticket:  SessionTicket;    /* NEW */
> rather than as
>               case new_session_ticket:  NewSessionTicket; /* NEW */
> 
> This emphasizes the fact that the contents of the ticket sent 
> by the client is expected to be identical to the contents 
> previously sent by the server, and it reduces the number of 
> structs that the reader/implementor must understand and implement.
> 

[Joe] OK, I think this makes sense. 

> 
> 3. Regarding the Sample Ticket Construction, a few 
> suggestions based on the belief that many implementors will 
> follow it to the letter, as if it were a specification.
> 
> 32-bit value will limit the space.  I suggest making it 
> larger, e.g. an opaque of 16 or more bytes, with strong 
> advice that this is NOT the place to store the key itself.  :)
> 

[Joe] It would seem that 32 bits would allow for plenty of keys.  What
is the advantage of making it larger?  Does it help with key management?

> ExampleStatePlaintext to contain a large random value, to 
> thwart known plaintext attacks on its contents.
> 

[Joe] Since we are using a random IV I'm not sure why we would need an
additional confounder.  How does a large random value help? 

> ExampleTicket should include the complete encoded contents of 
> the fields that preceed it in the ExampleTicket, including 
> the encoded length(s).  That will allow the MAC to be 
> computed with just a single input, without having to copy 
> data to eliminate the length(s).
> 

[Joe] Good suggestion. 

> 4) Regarding the paragraph that reads:
> 
> >    It is possible that the session ticket and master 
> session key could
> >    be delivered through some out of band mechanism.  This 
> behavior is
> >    beyond the scope of the document and would need to be 
> described in a
> >    separate specification.
> 
> Rather than suggesting that "it is possible", I'd prefer a 
> more forceful statement that methods of delivering the 
> tickets and/or keys out-of-band are out of scope and 
> non-interoperable with this specification.
> Maybe such a statement belongs in a separate section of the document.
> 
> --
> Nelson B
>

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 30 Sep 2005 16:47:14 -0700

Hi Nelson,

We had discussed keeping the server side cache mechanism separate from
the client side cache mechanism when implementing this in case a server
had some reason for supporting both.  If a server did not want to store
state then it would send an empty session ID.  The server could decide
to send both a ticket and session ID if it intended to store state.
Likewise the client could decide to send both a session ID and ticket,
then the server could decide which to honor.  If the server returns an
empty session ID (and continues on to the finished message) it is using
the ticket, if it returns the session ID then it is using the server
cache.

In the case where a client side ticket is used and an implementation
needed a session ID associated with the ticket it could generate this
locally as you stated.  For the server this could be stored in the
ticket, on the client it could be a hash of the ticket.  I'm not sure if
we should cover this local implementation issue in the spec or not.  

Joe 

> -----Original Message-----
> From: Nelson B. Bolyard [mailto:[email-masked]] 
> Sent: Thursday, September 29, 2005 5:04 PM
> To: Salowey, Joe
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> 
> Joe, et. al. TLSers,
> 
> My concern about the server sending both a session ID and a 
> ticket is that it seems to me that when a server sends a 
> session ID in the server hello, that amounts to a commitment 
> by the server to restart the session later if the client 
> sends that session ID in a client hello (within the session 
> lifetime, and assuming the session has not been invalidated), 
> even if the client does not present the ticket for that session.
> 
> By that reasoning, requiring the server to send a session ID 
> with the ticket, also obligates the server to keep that 
> session info in its own session cache, so that it can later 
> restart that session.  If the server is so obligated, the use 
> of the ticket does not relieve the server of the burden of 
> keeping its own copy of the session state.  But it is the 
> relief of that burden that motivates this entire idea, IMO.
> 
> If the server is NOT going to keep a copy of the session 
> state, and will NOT be able to restart that session later 
> (unless the client also sends in the ticket), then what is 
> the value of the server sending that session ID?  To whom is 
> that non-reusable session ID of value?
> If the client cannot rely on that session ID for session 
> restart purposes, then of what value is that session id to the client?
> 
> In answer to those questions, it has been suggested to me 
> that there are TLS implementations that make the TLS session 
> ID available to the application that uses it, so that the 
> application can correlate its own data to the TLS session.  
> It has also been suggested that there MAY be TLS 
> implementations that allow the applications that use them to 
> ask the TLS code to restart a specific session by specifying 
> the session ID.
> This would suggest a possible use for session IDs, even when 
> those IDs cannot be used to restart sessions.
> 
> However, I think that such applications may already be in 
> trouble, because the existing TLS RFC does not require TLS 
> servers to always send a session ID in the server hello.  So 
> clients that depend on non-empty session ID strings may 
> already fail with those servers.  Further, the TLS 
> implementation could offer its own substitute string locally 
> in such cases.
> 
> In order to properly set a client's expectation regarding the 
> ability to subsequently restart a session based on the 
> session ID alone, I think it is logical to NOT send the 
> session ID in the cases where the ticket is required to 
> subsequently restart the session, and in which the session 
> cannot be subsequently restarted based on session ID alone.
> 
> /Nelson
>