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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
