On Tue, Jan 21, 2020 at 07:57:27PM +1100, Martin Thomson wrote:
> On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote:
> > There's no need to exclude valid use-cases. The refined proposal
> > is rather non-invasive, and handles this case cost-effectively
> > on clients that re-use tickets (and don't use early-data, ...).
>
> I don't find your arguments persuasive. This adds complexity
> specifically to address a case that has - in the general case -
> suboptimal characteristics, both in terms of forward secrecy and
> linkability. Whether or not there are specific cases that might
> tolerate these suboptimalities, the complexity and risks are borne by
> everyone.
* Switching to a new ticket is of no help if the server is still
using the same STEK. Any forward-secrecy concerns are a function
of the frequency of STEK rotation on the server.
* We work in noticeably different application spaces. SMTP client
MTAs send 220 greetings and EHLO commands identifying themselves
in the clear prior to the STARTTLS handshake. MTAs don't roam
from network to network, and linkability of traffic is not a
concern.
* Postfix, for example, rotates STEKs by default once an hour,
making the forward-secrecy exposure quite limited.
* Clients don't use the same ticket indefinitely, they too discard
stale tickets, if the server does not beat them to it.
The requested change is rather minimal, it merely asks the server to
intepret 0 as "optional ticket" rather than "no ticket" reserving the
last code point (not uncommon to have make it special) as a no-go
sentinel.
Even if the proposal is not compelling for some, it allows additional
legitimate use-cases at negligible cost. So barring some actual
problem, it is hard to see on what basis it can be reasonably excluded.
That's all from me. Thanks.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
