Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

[Viktor Dukhovni <[e-mail]>]

On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:

> > Yes. I think Viktor's use case is one to not bugger
> > up (even if one doesn't need to support it) and don't
> > see how supporting it breaks something. (While also
> > disliking generic ticket reuse.)
> 
> It's not the usecase: it's the program. Postfix made architectural
> choices that make storing tickets allegedly expensive.

These fit into a existing archicture of security-hardened
privilege-separated ephemeral processes that handle a modest number of
deliveries and exit to be replaced by new processes, concurrent
delivery (within sensible bounds) to the same destination, because
serializing all output to the same destination really kills
performance, ...

The architecture is actually reasonably well thought out.  It is true
that Postfix could probably learn to have a multi-slot cache, and to
keep updating on each and every resumption.  But the shared ticket cache
is backed by Berkeley DB or LMDB, and especially in the case of LMDB's
copy-on-write design a high write rate (hundreds of new tickets per
second) is not particularly appealing.

In any case, Postfix is but an example of an application where ephemeral
tickets are mere security theatre, there is simply no privacy benefit,
and no plausible use-case for early data.

I am all down with discouraging ticket reuse, not enabling it by
default, ... but none of that amounts to a sound reason for precluding
reuse where non-reuse has demonstrably no value.

> I would be a lot more sympathetic if Viktor could provide actual
> measurements with actual numbers demonstrating that rewriting tickets
> is an insurmountable obstacle, given all the other time taken by
> opening connections and sending mail.

Why does it have to be an insurmountable obstacle.  What's wrong with
the observation that I have a well-oiled mature code-base that works
well with multi-use tickets, and would need significant refactoring to
take advantage of ephemeral tickets.

It is true that with returning a fresh ticket each time, the cache churn
is not a *disaster* for Postfix, but it is unnecessary, and not just
Postfix, but also other application can benefit from avoiding ticket
churn security theatre.

> There also is the possibility that a different architecture that
> reduces contention on the cache (say by not having multiple processes
> attempting to open connection to the same server at once, or switching
> to storage system that accomodates multiple simultaneous writers)
> would have better performance.

So I gather I should trade-off optimizing mail queue management for
optimizing ticket cache management?  (I don't think so...)

> 0-RTT=> replay=> either single use tickets or idempotent methods only.
> And then we learned that websites don't have idempotent GET always.
> Hence the interest in server side enforcement of single use tickets.

There's no GET in SMTP.  The transaction starts with a 220 greeting
from the server to the client.  Then eventually STARTTLS, and a new
EHLO from client to server.  There's no 0-RTT, no early data, ...

I think a singular focus in this WG on HTTPS as the sole motivating
use-case is unfortunate.

-- 
    Viktor.