Hi Tom.
Again, I know little about this, but from what I understand PostgreSQL wouldn't actually need to do/implement anything here - the session ticket might be used only to abbreviate the SSL handshake (this would explain why it's on by default without any application support). In other words, simply setting the session context id may make the problem go away and at the same time unlock the abbreviated SSL handshake optimization. I could be wrong about this though.
Whether the above is correct or not, SSL resumption - which removes a network roundtrip from the connection process - may be a worthy optimization even for long-lived connections such as PostgreSQL, although obviously much less valuable than, say, short-lived HTTP connections.
But regardless, it seems that as you say: if you *don't* want to support resumption, you're required to explicitly disable it with SSL_OP_NO_TICKET.
Just to give some context, Npgsql has its own, internal TLS implementation which does not implement session tickets at the client side - this is the workaround currently used. However, it would be much better if the standard .NET SSL implementation could be used instead (i.e. I'm hoping a backport would be possible here).