On Thursday, 23 January 2020 03:14:55 CET, Viktor Dukhovni wrote:
On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote:
- either the TLS server says "here's a ticket and you MUST or MAY
replace the one you already had"
or
- the TLS client gets to ask for no unnecessary new tickets
Now the first alternative would be infeasible to adopt because it would
require new OpenSSL callback APIs, and anyways would be a more invasive
change to TLS than the ticketrequest extension makes.
Nothing says you have to remember tickets, so unless I'm missing
something the semantics already are the second one.
I want to use tickets for resumption, so naturally I have to remember
them. I also don't actually get to directly see the tickets, rather
OpenSSL invokes a "new_session_cb" callback after updating the current
session with newly received tickets.
Since I have a shared cache, I have to perform the work of storing the
updated sesion, so that other SMTP delivery agents get to see the new
ticket.
I can't just ignore the ticket, since the reason for the new ticket may
be that the old one has expired, either after some period of reuse, or
because the server only ever issues single-use tickets.
The deployed base of Postfix servers issues multi-use tickets (always,
there's no extension to tell me otherwise), and sends zero tickets
on resumption, so I need to not just throw away tickets that are
still valid.
I wonder if the approach with a database with strict ACID-ity is the
correct
one for ticket storage.
What I mean, is that, especially in postfix case, using slightly older
ticket
that it could will have minimal impact on the connection. Thus a database
that is basically append only, with clients that look for newest ticket
(and disregard races on this lookup) and a garbage-collection process that
removes old tickets every few hours will work ok.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
