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

From: Eric Rescorla <[email-masked]>
Date: Fri, 09 Sep 2005 07:49:43 -0700

A while back I asked whether there was WG enthusiasm for
draft-salowey-tls-ticket-03 and while there seemed to be
some interest, there wasn't enough in my opinion to justify
making it a WG work item.

Accordingly, I asked Joe to go ahead with it as an individual
submission. He has now prepared a new version which he feels
is ready to submit to the IESG. Because this is a modification
to a core TLS mechanism I would like to get some review from
the TLS WG. Can I please get 3 volunteers who will commit
having reviews of this document by October 1?

Thanks,
-Ekr

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 12 Sep 2005 15:02:59 -0700

> having reviews of this document by October 1?

I volunteer to review
http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-04.txt
this month.

I'm assuming the various volunteer reviewers would like to read each
others' reviews.  Shall we use this mailing list to discuss it?
Is Joe on this mailing list?
Or, Shall we form another list to discuss it?
Or will someone inform us of the other reviewers so that we can CC
the others?

Regards,

/Nelson

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2005 18:09:43 -0700

> others' reviews.  Shall we use this mailing list to discuss it?

Please.

> Or will someone inform us of the other reviewers so that we can CC

I'll post a list once I get three.

Only one person has volunteered so far. Can I please get two more
volunteers?

thanks,
-Ekr

---

From: Tim Dierks <[email-masked]>
Date: Mon, 19 Sep 2005 12:59:09 -0400

OK, I took a look. Here are my thoughts:

 - If the server-side implementor screws up his ticket security, it's
a catastrophic problem for system security. I'm concerned about
creating more possible implementation pitfalls for TLS implementors,
especially ones that implicitly ask them to do their own crypto
design. I suggest we specify a structure for the ticket, in particular
how it is encrypted & authenticated, and recommend use of that
structure as a best practice. I think this only requires expanding
some language around your example, which looks pretty good. In fact,
I'd be open to specifying the example as a part of the standard, with
a parenthetical note that, because the contents are opaque to the
client, the structure is not subject to interoperability concerns, so
implementors can safely diverge from the standard, although they must
take security concerns very seriously to do so. (And furthermore,
clients must not examine the contents of a ticket under the assumption
that the server complies with the standard [although key_version is
the only structured unencrypted field].)

 - I'm not sure when the new message with the ticket should be sent.
Because the server cannot easily revoke a ticket that has been sent,
the ticket shouldn't be transmitted until the server is willing to
commit to the session's validity and accuracy. The current location
(after client sends Finished, but before server sends Finished) seems
OK, but I believe it should be specified that the ticket should not be
sent until the server validates the client's Finished message: I don't
have an exact attack, but this seems prudent.

 - We should specify the exact behavior if a server accepts a ticket,
but the connection then fails to complete and validate: the client
must discard the ticket.

 - Can the server send NewSessionTicket on a resumed session? I'm sure
people will want to do this at some point, because they'll be storing
something in the ticket they want to update (last connection time, for
example).

 - Tim

---

From: "Nelson B. Bolyard" <[email-masked]>
Date: Fri, 23 Sep 2005 13:21:27 -0700

Comments on draft-salowey-tls-ticket-04.txt

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.

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?

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.

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

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.

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

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