Subject: [TLS] RE: few comments on salowey-tls-ticket-03

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 4 Jan 2006 15:08:21 -0800

Hi Amir,

Thanks for the review and your support. The latest draft is -06 and can
be found at
http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-06.txt.
I'm forwarding your comments to the TLS list where the this draft has
been discussed and to the IESG who are currently evaluating the document
for publication as an RFC.  Comments are included below.

Thanks,

Joe

> -----Original Message-----
> From: Amir Herzberg [mailto:[email-masked]] 
> Sent: Monday, December 26, 2005 11:50 PM
> To: Zhou, Hao; Salowey, Joe; [email-masked]; 
> [email-masked]; Igal Ioffe
> Subject: few comments on salowey-tls-ticket-03
> 
> Friends, I am very supportive of the TLS ticket idea, and 
> cover it in my 
> network security course as part of the TLS lecture (which you 
> can find 
> in my site, btw). A few comments on the draft (-03, July 15) 
> version; if 
> there is an appropriate mailing list, please let me know (and forward 
> the message to it).
> 
> 1. Expiration time. Tickets clearly would (usually) have expiration 
> time. It makes sense for the server to indicate this, so that 
> the client 
> can discard expired tickets. It may make sense to give some 
> guideline as 
> to sensible expiration time, in particular so that people 
> realize that 
> it makes sense to use substantially longer periods cf. to the TLS 
> session lifetime.
> 

[Joe] The client does not know the expiry time of the ticket, this is
consistent with current operation of TLS session resumption.  If the
server does not accept the ticket then the conversation falls back to
the full handshake.  I think adding expiration times would complicate
the client implementation.  We currently mention longer life tickets in
the introduction, but we do not discuss ticket lifetime much outside
this.  

> 2. A missing security consideration: client identification 
> (exposure to 
> anonymity). TLS tickets may be cached for substantial 
> periods. Users may 
>   move during these periods, e.g. from home to cafe. The ticket could 
> allow identification of the user; this could be a concern in some 
> scenarios. Notice that the session identified of regular TLS can also 
> have this property but is short lived and therefore less of 
> concern. We 
> can solve this problem if needed, by encrypting the ticket using the 
> server's public key, or maybe using some shared-key 
> mechanisms; I'm not 
> sure if the complexity is worth the benefit, but at least 
> this should be 
> mentioned, imho.
> 

[Joe] Yes, it is probably worthwhile to add a section in the security
considerations on this.  I agree that it probably isn't worth the
complexity to try to address this at this point. 

> Is there a good reason for sending the newticket in the clear i.e. 
> before CSS? Sending after CSS would have reduced this 
> exposure, esp. if 
> the server changed the ticket at every connection.
> 

[Joe] The TLS spec indicates that the Finished message must follow the
Change Cipher Spec message so we thought it would be more of a deviation
from the existing TLS standard and TLS implementations.  It was also in
line with what was provided in [CSSC]. 

> 3. I think the `sample ticket` (section 4) should be given as 
> a standard 
> `ticket format`: this will facilitate multiple server 
> implementations to 
> support same ticket, which is a possible scenario; and why 
> not? OTOH, I 
> think the ticket should include a `ticket format identifier` (as an 
> OID), allowing easy identification of the ticket format, for 
> versioning 
> and for supporting different ticket mechanisms. For same 
> reason, it may 
> make sense to allow sending multiple tickets.
> 

[Joe] This comment has come up before. The specification is not intended
to provide interoperability between different server implementations.
This would require a lot more specification and complexity.  The sample
ticket is included as a reasonable example that implementers can use
instead of trying to invent their own.  The ticket is issued by the
server and understood by the server. Adding more structure to the ticket
will tempt clients into interpreting the ticket which will have negative
impacts on interoperability. If deployment experience shows that
interoperability  between different servers is useful and achievable
then we can look at this again. 

[CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
              caching for TLS", Transactions on Information and
              System Security (TISSEC) , Volume 7, Issue 4,
              November 2004.

> -- 
> Best regards,
> 
> Amir Herzberg
> 
> Associate Professor
> Department of Computer Science
> Bar Ilan University
> http://AmirHerzberg.com
> Try TrustBar - improved browser security UI: 
> http://AmirHerzberg.com/TrustBar
> Visit my Hall Of Shame of Unprotected Login pages: 
> http://AmirHerzberg.com/shame
> 

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

---

From: Amir Herzberg <[email-masked]>
Date: Sun, 08 Jan 2006 11:11:11 +0200

Joe, thanks. Few comments below.

> I'm forwarding your comments to the TLS list where the this draft has
I somehow got unsubscribed from TLS... resubscribed now. Tks!

>>the client can discard expired tickets. It may make sense to give some 
>>guideline as to sensible expiration time, in particular so that people 
>>realize that it makes sense to use substantially longer periods cf. to the TLS 
>>session lifetime.
> 
> the full handshake. 
Sure. But you ignored the point I made: the hope is that tickets can be 
cached for much longer than TLS session state. Therefore, ticket 
lifetime should be much longer - and clients need to know when to 
discard ticket. Also, ticket are sent by server and are variable length, 
probably often longer than TLS session state. The TLS tickets are 
comparable to HTTP cookies.

> I think adding expiration times would complicate
I think that adding ticket lifetime is not substantial complication. Not 
including it now may lead to adding it later which will be more complex. 
Of course, the lifetime field can be optional, also clients are allowed 
to erase a ticket before the requests lifetime.
>>(exposure to anonymity). TLS tickets may be cached for substantial 
...
>>mechanisms; I'm not sure if the complexity is worth the benefit, but at least 
>>this should be mentioned, imho.
> 
Ok, so we are in agreement here.
> line with what was provided in [CSSC]. 
Hmmm. I'm not sure this is much of an argument.
I think privacy adovcates may consider this an insuffient reason. But 
I'll leave it to them.
> then we can look at this again. 
Reasonable.

Thanks!
-- 
Best regards,

Amir Herzberg

Associate Professor

---

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 24 Jan 2006 16:49:08 -0800

> From: Amir Herzberg [mailto:[email-masked]] 
<snip>
> to erase a ticket before the requests lifetime.
[Joe] OK, how about 

"The SessionTicket handshake message has been assigned the number
TBD2.  The definition of the SessionTicket handshake message is given
at the end of this section.  The message contains
ticket_lifetime_hint which is a hint of the ticket's lifetime in
seconds as a 32 bit unsigned integer in network byte order.  A value
of zero is reserved to indicate that the lifetime of the ticket is
unspecified.  A client MAY delete the ticket when the time expires.
A server MAY treat a ticket as valid for a shorter or longer period
of time than what is stated in the ticket_lifetime_hint.  The client
MAY delete the ticket before the lifetime has elapsed.

  struct {
          HandshakeType msg_type;
          uint24 length;
          select (HandshakeType) {
              case hello_request:       HelloRequest;
              case client_hello:        ClientHello;
              case server_hello:        ServerHello;
              case certificate:         Certificate;
              case server_key_exchange: ServerKeyExchange;
              case certificate_request: CertificateRequest;
              case server_hello_done:   ServerHelloDone;
              case certificate_verify:  CertificateVerify;
              case client_key_exchange: ClientKeyExchange;
              case finished:            Finished;
              case session_ticket:      SessionTicket; /* NEW */
          } body;
      } Handshake;

      struct {
          uint32 ticket_lifetime_hint;
          opaque ticket<0..2^16-1>;
      } SessionTicket;