Re: tls 1.3: sending multiple tickets

On Fri, Jul 26, 2024 at 10:23 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> We turn off TLS session tickets for two reasons: a) we don't support TLS
> session resumption, and some resumption capable client libraries can experience
> connection failures if they try to use tickets received in the setup (Npgsql at
> least had this problem in the past); b) it's network overhead in the connection
> setup phase which doesn't give any value due to us not supporting their use.
>
> TLS tickets were disallowed in 2017 in 97d3a0b09 but as Andres found out,
> TLSv1.3 session tickets had a new API which we didn't call and thus issued
> tickets.

Thanks much for this explanation.

> > I don't doubt that you're doing the right thing here but it'd be nice
> > to document why it's the right thing someplace.
>
> I can add a summary of the above in the comment for future readers if you think
> that would be useful.

I think having (a) and (b) from above at the end of the "Disallow SSL
session tickets" comment would be helpful.

While I'm complaining, the bit about SSL renegotiation could use a
better comment, too. One of my chronic complaints about comments is
that they should say why we're doing things, not what we're doing. To
me, having a comment that says "Disallow SSL renegotiation" followed
immediately by SSL_CTX_set_options(context, SSL_OP_NO_RENEGOTIATION)
is a good example of what not to do, because, I mean, I can guess
without the comment what that does. Actually, that comment is quite
well-written in terms of explaining why we do it in different ways
depending on the OpenSSL version; it just fails to explain why it's
important in the first place. I'm pretty sure I know in that case that
there are CVEs about that topic, but that's just because I happen to
remember the mailing list discussion on it, and I don't think every
hacker is contractually required to remember that.

I don't want to sound like I'm giving orders and I think it's really
up to you how much effort you want to put in here, but I feel like any
place where we are doing X because of some property of a non-PG code
base with which a particular reader might not be familiar, we should
have a comment explaining why we're doing it. And especially if it's
security-relevant.

-- 
Robert Haas
EDB: http://www.enterprisedb.com