> On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > > > I would make several points here: > > > > 1. RFC 8446 explicitly discourages ticket reuse > > (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we > > should not be designing an extension to enable reuse. While it's > > potentially true that some applications do not benefit from > > non-reuse, creating a set of mechanisms around reuse risks those > > mechanisms being used in settings where reuse would be > > bad. Moreover. just because at present sending MTAs have weak > > privacy properties does not mean that we should bake in this > > situation permanently. > > Indeed I agree that ticket reuse is often undesirable, and expect that > it will be avoided in many cases. So I am somewhat sympathetic to the > above as a starting point for the analysis. > > That said, I don't see that making reuse easier to negotiate is likely > to create significant opportunities for misuse.
I'm actually making several points here: 1. TLS 1.3 takes the position that reuse is bad and that position is for good reasons, so we shouldn't undercut it in a new extension. 2. Creating a mechanism which encourages reuse increases the risk of reuse. You are responding to number (2), and I'll respond to that below, but I think the controlling point is actually (1). We shouldn't encourage reuse, period. > - Both the client *and* the server would need to opt-in to reuse. > > * Even if the client asks for reuse, the server can invalidate > the old ticket (something it would need to be able to do > already to ensure non-reuse) and send a fresh one anyway. > > The client would have to replace the old with the new, since > it has to assume that the old is now likely invalid. > > * Even if the server is willing to reuse, if the client asks > for a new ticket, the server has to assume the client has > a single-use cache, and should vend a new ticket. > > so it takes bilateral coordination to arrive at reuse, and > so accidental reuse in applications where it is inappropriate > requires errors on both ends. The issue is less accidental reuse than joint misconfiguration (e.g., bad defaults or bad advice in some Stack Overflow document). > > 2. The additional cost of multiple tickets seems extraordinarily > > small, so I am not at all persuaded that there is enough value in > > this use case to justify adding new protocol machinery, even > > ignoring point (1) above. > > Postfix has a shared cache (indexed by destination domain+mx host) for > multiple independent processes racing to use the cache to make remote > SMTP connections. > > Frequent writes to that cache create measurable overhead and still don't > prevent reuse. I'm sorry to say that I'm not that sympathetic to this position. I appreciate that it's inconvenient for Postfix to have frequent writes to the ticket cache, but what you propose to do is hoist this implementation idiosyncracy into the specification, and I don't think that that's a good tradeoff, both for complexity and because the > Transmission of unnecessary tickets is also wasteful of > network and other server resources. Well, my position here is that these tickets aren't unnecessary, because you should be using them, rather than violating the SHOULD in the 8446. > Erasing tickets on first use would be unwise, most existing servers will > not presently return a fresh ticket on resumption. This seems like a defect in those servers. However it can be handled by not erasing tickets until a new ticket is provided. > > > 3. If there *is* such value, then you can register your own extension > > which allows you to say the orthogonal thing, namely "don't send me > > any tickets at all if you are resuming". This would be more > > flexible in that you could then say "I would like 10 tickets, but > > only if you don't resume". Note that > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would > > allow you to do this efficiently. > > This is an interesting idea, but how would the two extensions interact? I would imagine the logic would be: If !reuse || !present(reuse extension) { send min(max-local-tickets, tickets-requested-extension-present ? tickets-requested-extension-value : 1) } > And wouldn't that interaction add more complexity? Perhaps. At least in NSS, I imagine it would be pretty comparable, assuming we opted to implement the non-reuse one at all. > By hypothesis > clients that are willing to reuse tickets don't really need more than > one at a time. Is there a clear use case for multiple concurrent > reusable tickets. Yes, I see your point here. I don't have a clear case for this, but I'm also not sure that there isn't one: concurrent usage and serial usage are not necessarily the same. > > Thus, I would prefer to advance this document as-is. > > Thanks for the substantive response. Much appreciated. I hope you're > willing to address the above reaction, I am trying to find common > ground that addresses your concerns and mine. And thank you for your substantive response. I am not sure if we will be able to find common ground however. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
