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

[Benjamin Kaduk <[e-mail]>]

On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
> On Wed, Mar 4, 2020 at 6:07 PM Stephen Farrell
> <[e-mail]> wrote:
> >
> >
> > Hiya,
> >
> > On 04/03/2020 16:06, Sean Turner wrote:
> > >  Must the ticket reuse use case be addresses
> > >  in draft-ietf-tls-ticketrequests?
> >
> > 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.
> 
> 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. 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.

I don't think Viktor's obligated to do so.
Everyone will make their own decisions based on their perception of
the cost of the various options.  While having hard data can be useful
in shaping everyone's perceptions of the cost of a given operation, we should
not expect that this requested hard data will magically force everyone to
behave as if additional ticket issuance has negligible cost.  There may well
be other factors in play, even qualitative ones, including personal opinions
about architecture design, preparedness for large post-quantum certificates
in the future, etc., and Viktor is well within his rights to make such
a decision even in the absence of "hard data" about CPU cycles and bandwidth.
As it happens, Viktor's decisionsi affect a nontrivial amount of internet
traffic due to his role maintaining Postfix.  We can supply facts and
reasoning to attempt to influence his decisions, but they remain his
decisions to make, not ours; I recall that it was previously discussed that
Postfix currently performs ticket reuse *always*, and having the extra
flexibility of the various technical mechanisms under discussion would
allow for that to change and allow for single-use tickets to enter in
the situations where they make sense.

> > I also note what seems like a correlation between
> > people's yes/no opinions on this and whether or not they
> > (or sponsors/employers) are involved in implementing
> > a web browser. Not sure if that implies a technical
> > difference or just relates to understandable priorities
> > but I'm sure the chairs will factor that into evaluating
> > the mails in this thread.
> 
> 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.

Please don't assume that the web/HTTP is the only consumer of TLS.
Yes, web servers are very interested in enforcing single-use tickets;
they are not the only kind of TLS server we should consider.

Thanks,

Ben