Thanks for your review, Bernard! Please find below some replies to your comments: > 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. No, the specification does not mandate this: the performance benefits will just be smaller in heterogeneous deployments. In the extreme case (client gets different server every time, and none of the servers can understand tickets generated by other servers), it will degrade to normal TLS (full handshake done every time). However, the extreme case is probably not the most common one. If you're sharing the same private key between multiple TLS servers, they're probably often homogeneous. And even if they are not, various load balancers (etc.) often some have amount of "stickiness", meaning the client usually gets the same server as last time. Most of these things are probably implementation considerations that we don't have to include in the specification. > 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. If you scroll down a couple lines, you'll find the "StatePlaintext" structure which does describe it. > For example, there is no requirement for binding between the key > and the client identity or session-id. The sample ticket construction does include the client identity, and the interaction with session-id is described in section 3.4 (the session ID is empty). What the specification does not currently have is a detailed "instructions for those who want to design their own ticket format" section. Personally I do not think it would be a very useful thing to include. It might actually encourage people to design their own ticket formats, and there's no way the section could cover all the possible ways to get things wrong :-) > 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?) The document does try to say that people who don't know what encryption algorithms are good enough for their environment should not design their own ticket formats :-) > 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. The specification provides crypto-agility by not mandating the use of the sample ticket format from Section 4. The sample ticket format doesn't contain an algorithm identifier because we didn't think of any case where the same server would want to issue tickets using multiple algorithms (e.g., use different algorithms for different clients). > 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? The recommended ticket construction does include a timestamp saying when the ticket was issued. Best regards, Pasi _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf