Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Hubert Kario <[e-mail]>]

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