Review of draft-salowey-tls-ticket-06.txt This document describes a mechanism for TLS session resumption without Server-Side state. However, the document does not actually mandate support for any particular ticket format, and the recommended ticket format appears to lack some features, such as key-lifetime specification, support for multiple algorithms and binding of the key to its context. I'd also note that this document has been the subject of two IPR disclosures: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=532 https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=537 I am therefore concerned about whether this specification is likely to produce widely deployed, interoperable implementations. ------------------------------------------------------------------- Section 4 states: " This section describes a recommended format and protection for the ticket. Note that the ticket is opaque to the client so the structure is not subject to interoperability concerns, so implementations may diverge from this format. If implementations do diverge from this format they must take security concerns seriously." There are a number of issues with this: 1. Interoperability problems. While it is true that changes to the ticket format will not cause *client* interoperability problems, it will cause interoperability problems with servers. For example, if heterogeneous TLS servers are deployed, then it is possible that a ticket given out by one server will not be able to be interpretted by another server in the same cluster. As a result, this specification essentially mandates that TLS deployments be homogeneous. 2. Without a mandated ticket format, the opaque blob sent to the client could be more akin to a cookie than a ticket. Section 5 does not contain normative language (e.g. no use of MUST, SHOULD, etc.) relating to the required security properties. In fact, it is not even clear that the recommended ticket construction includes all of the necessary security properties. For example, the ticket structure refers to "opaque encrypted_state" but does not describe what kind of stat needs to be included here. For example, there is no requirement for binding between the key and the client identity or session-id. Section 5.2 states: "A TLS server MUST use strong encryption and integrity protection for the ticket to prevent an attacker from using a brute force mechanism to obtain the tickets contents." While the recommended ticket construction uses 128-bit AES in CBC mode and HMAC-SHA1, there is no general statement about what "strong encryption" means. Perhaps a reference would be appropriate. The specification also doesn't state how the MAC and encryption keys relate (presumably they need to be cryptographically independent, right?) 5.3 Forged Tickets A malicious user could forge or alter a ticket in order to resume a session, to extend its lifetime, to impersonate as another user or gain additional privileges. This attack is not possible if the ticket is protected using a strong integrity protection algorithm such as a keyed HMAC-SHA1. This brings up the issue of how this specification provides for crypto-agility. The recommended ticket construction does not include an algorithm identifier, and instead mandates use of 128-bit AES in CBC mode and HMAC-SHA-1. What happens if alternative algorithms are required? The IV and MAC fields are of fixed size. 5.5 Ticket Protection Key Lifetime The management of the keys used to protect the ticket is beyond the scope of this document. It is advisable to limit the lifetime of these keys to ensure they are not overused. Since there is no server-side state, and the recommended ticket construction does not include a key-lifetime, how is the server to limit the lifetime of the tickets? _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf