On Tue, Apr 16, 2019, at 18:36, Erik Sy wrote: > Hi Martin, > > can you please explain, why you think this is not the right solution?
To recap, the draft proposes an empty extension in ClientHello, which the server, at its discretion, includes in Certificate. There are two insights that are important here: 1. The client could, if it chose, send any session ticket from any server to any other server[1]. The reasons for not doing that are primarily linkability: by using a session ticket it links the connection where it is used with the connection where it was acquired. 2. The linkability thing means that clients can't reuse session tickets because that changes the set of entities that can link sessions from (issuer+consumer) to (issuer+consumer+network path). This is what leads us to strongly recommend using tickets at most once. The second observation is what drives the signal. We want to have a signal so that the client can make the resumption attempt without wasting the ticket on a server that simply cannot use it. I think that the signal could be attached to NewSessionTicket instead: The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these. [1] What it means to resume with a completely different server identity, where the client has seen no previous authentication, is a separable question. And I don't think that the current draft goes far enough to address this complex question. It currently says: This resumption group is formed of all SNI values that are valid for the presented server certificate. That is convenient and probably ultimately a good baseline for this, but it doesn't capture some of the things we learned about the scope of server authority out of HTTP/2 and the ensuing work. I think that this needs to transition - at least conceptually - into the application layer and rely on the client's understanding of what identities the server holds. I'm OK with adoption without addressing that concern, but it does need to be addressed. Finally, there is some text in the draft that I think needs to be removed. For example, the normative text on cache lifetime here: According to [RFC8446], clients MUST NOT cache tickets longer than seven days. Note, that TLS resumption enables a server to link resumed connections to the same client. A study on the feasibility of this tracking mechanism can be found in [TRAC]. To protect the client's privacy against tracking via this mechanism, it is RECOMMENDED to cache resumption tickets only for ten minutes. ....or this: To optimize the performance benefit of this extension, the server's certificate is RECOMMENDED to only include SNI values that mutually support the resumption of their TLS connections. There's enough there that I think that another iteration would be wise before adoption, that's all. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
