Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Viktor Dukhovni <[e-mail]>]

On Sat, Oct 05, 2019 at 05:06:04AM -0700, Christopher Wood wrote:

> > The use-case is clients and servers that don't make use of
> > early-data, and don't need to avoid traffic analysis.  For
> > example, MTA-to-MTA traffic, where the client even identifies
> > in clear text with "EHLO".  Here ticket reuse is the norm,
> > and renewal is only needed as tickets age.
> > 
> > [ I hope I managed a suitably concise description this time... ]
> 
> You did indeed! However, as I'm not sure we should be encouraging ticket
> re-use. I think asking for 1 upon resumption would be the norm, which
> should address this case.

Granted, ill-conceived ticket re-use should not be encouraged, in
fact should be prominently discouraged.

But perhaps the MTA-to-MTA use-case has more general applicability
in a broad class of server-to-server (datacentre-to-datacentre)
traffic, where the client has a long-term stable IP address, and
often a long-term affiliation with a single downstream peer.

An obvious example that comes to mind is a reverse-proxy that
terminates and resumes TLS.  At various $jobs I've helped folks
design/deploy such beasts in the DMZ.  Here there's a steady stream
of traffic between two nodes, and traffic-analysis "privacy"
considerations around ticket re-use don't come into play.

> (That is, I'm not sure adding more information to the signal to support
> the *as needed* case is worth the added complexity.)

That's the key question.  Such a signal could perhaps steal the
high-bit of the ticket count, limiting the count to at most 127.
Or alternatively the extension could send

    * 0 to mean no tickets ever (client has no ticket cache)
    * 1 to mean none required, but refresh as needed
    * n=2 or more to mean please send n-1 tickets.

This keeps the structure of the extension simple: for most clients
just send n+1 for n∈[1,254].

On the server side for n∈[2,255], just vend the lower of the server's
limit and n-1, for 0 send no tickets, which leaves only "n=1" for
the server to handle specially, by renewing the ticket if it is
either a single-use ticket or suitably dated.

-- 
	Viktor.