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

From: [email-masked]
Date: Thu, 6 Oct 2005 17:23:22 +0300

Rob Dugal wrote:
	
> Actually having a ticket doesn't guarantee the server will
> later resume with it.
>
> For example, the ticket could be old and the server might not want
> to use it.  My concern is that without knowing that the server will
> resume using the ticket it get's a little difficult to know what
> handshake messages the server will respond with. When the server
> resumes with the sessionID it is pretty clear because the server
> returns the same sessionID in the ServerHello as the client sent in
> the ClientHello. But in TLS ticket there is no clear indication from
> the ServerHello that the server will resume. And now there is also
> the proposal for allowing the server to send NewSessionTicket on a
> resumed session.

Hmm.. I agree, it would be nice to have an unambiguous signal 
in the ServerHello that tells the client resumption is happening.
This would be the case if we also included the normal sessionID
as I suggested earlier in

http://www.imc.org/ietf-tls/mail-archive/msg04709.html

> Which also brings up the question: what does the server do if it
> receives an invalid ticket, such as a forged ticket? Does it just
> ignore the ticket? Send an alert?

Same thing it does when it receives an invalid session ID:
ignores it and starts a full handshake.

Best regards,
Pasi

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 6 Oct 2005 09:32:11 -0700

Rob Dugal wrote:

>>> I think it would simplify client implementation if the server
>>> provided some indication it intends to proceed with resumption
>>> using the client's ticket. What about including an extension in the
>>> server hello that would indicate to the client that the server will
>>> resume using 
> the ticket?
>> Isn't that what providing the ticket means?
> 
> Actually having a ticket doesn't guarantee the server will later
> resume with it. For example, the ticket could be old and the server
> might not want to use it. My concern is that without knowing that the
> server will resume using the ticket it get's a little difficult to
> know what handshake messages the server will respond with. When
> the server resumes with the sessionID it is pretty clear
> because the server returns the same sessionID in the
> ServerHello as the client sent in the ClientHello. But in TLS
> ticket there is no clear indication from the ServerHello that
> the server will resume. And now there is also the proposal
> for allowing the server to send NewSessionTicket on a resumed session.
> 

[Joe] The client can tell if the server is resuming unambiguously using
the ticket by the subsequent message sent by the server.  A
NewSessionTicket Handshake message or a ChangeCipherSpec would indicate
a session resume using the ticket.  

> Which also brings up the question: what does the server do if
> it receives an invalid ticket, such as a forged ticket? Does
> it just ignore the ticket? Send an alert?
>
 
[Joe] It ignores the ticket and falls back to a full handshake.