Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Eric Rescorla <> Sun, 02 February 2020 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06D92120241 for <>; Sun, 2 Feb 2020 09:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JCWHguVfMlSu for <>; Sun, 2 Feb 2020 09:08:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B614912004D for <>; Sun, 2 Feb 2020 09:08:55 -0800 (PST)
Received: by with SMTP id h23so12138755ljc.8 for <>; Sun, 02 Feb 2020 09:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=F2qT7FeWZYf/b5iUR0Nr40cK7p1/rkgD7IWYMpAJZ3c=; b=TaNFk2XNMNRuMbkt+be++IsZc3+C5h3v+UwRfpRzH0O4Iuqplv4lQDPp6C00oZ+W7x oaHq4PmNUHpSn5MSds57TgkRLW1WIOFQhaO6TYayamge7lSrswOuoQck2zvItLzIEwpc 7fUFJg5cY4A4T/7V8IV1ko1+GEj9UA4dAW7waXOcwTzuyN6z1Tj070T21rGuxFQH0w0c cxP0+Iqo17VJg+6diX+lnJcDoYUyOaILd+KerQQTpsk18UhbeJcBLx4Q/BBOZLrSsNpA /uy8jk3CqClx/msNtb3sDIdFpcDC8/13C8Wiz5tt47x8WiQXbx694kaZ7dLgH6bwAYuG +t2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=F2qT7FeWZYf/b5iUR0Nr40cK7p1/rkgD7IWYMpAJZ3c=; b=HtD4Z1g/qjCJCrRd3CHq3VgRKUlzzBE1kK+GRDK7vPSneIEUz8QLsZ1bryG1bFFhj9 UP0M525LhKYn7y0np3pQtTmYy8S6emGS6NP/4VT3219mrugSlgBfKi87Qn4esBSn0Dc6 iY+XQVKreh0ZwkBlJ+/IiiagZ1copdd+DMSLqc/rtAXdWpsLqM63cSMh+QLIUO1dBmmb tTK7+kyhD17hnS42Mz3evR63vHtBnAHxDzVS48HQuJtw6MwE5nqLFmh5KnmhwD3qCTmf v5KFdcoTfNJLYN2BdToP+4gop/1QkMfm1HBJwU6MaD9Y7zRAuA0dlyfopuz6sq/GAfZJ Lpcg==
X-Gm-Message-State: APjAAAU2TdEXTtCrphgk/CLLql3SsI7WDciPisQfbpTINcpsAXoYQBN4 wd00AN3FZWJJzLiT6IZXsg5rqSUCy7DyVdQ82ZP34tOMCm8=
X-Google-Smtp-Source: APXvYqyL3uhiA3P+ak4O9B7N0TYU4Fkx9UNv48MxRR9YOAT2Br6NS+/5IKk4tk1Z+qhH3gj70fcnIJ0z1N80kXyeC/Y=
X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr11252852ljn.162.1580663333618; Sun, 02 Feb 2020 09:08:53 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Sun, 2 Feb 2020 09:08:17 -0800
Message-ID: <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="00000000000082ac97059d9adc50"
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Feb 2020 17:09:00 -0000

> On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
> > I would make several points here:
> >
> > 1. RFC 8446 explicitly discourages ticket reuse
> >    ( so we
> >    should not be designing an extension to enable reuse. While it's
> >    potentially true that some applications do not benefit from
> >    non-reuse, creating a set of mechanisms around reuse risks those
> >    mechanisms being used in settings where reuse would be
> >    bad. Moreover. just because at present sending MTAs have weak
> >    privacy properties does not mean that we should bake in this
> >    situation permanently.
> Indeed I agree that ticket reuse is often undesirable, and expect that
> it will be avoided in many cases.  So I am somewhat sympathetic to the
> above as a starting point for the analysis.
> That said, I don't see that making reuse easier to negotiate is likely
> to create significant opportunities for misuse.

I'm actually making several points here:

1. TLS 1.3 takes the position that reuse is bad and that position
   is for good reasons, so we shouldn't undercut it in a new

2. Creating a mechanism which encourages reuse increases the risk
   of reuse.

You are responding to number (2), and I'll respond to that below,
but I think the controlling point is actually (1). We shouldn't
encourage reuse, period.

>     - Both the client *and* the server would need to opt-in to reuse.
>       * Even if the client asks for reuse, the server can invalidate
>         the old ticket (something it would need to be able to do
>         already to ensure non-reuse) and send a fresh one anyway.
>         The client would have to replace the old with the new, since
>         it has to assume that the old is now likely invalid.
>       * Even if the server is willing to reuse, if the client asks
>         for a new ticket, the server has to assume the client has
>         a single-use cache, and should vend a new ticket.
>       so it takes bilateral coordination to arrive at reuse, and
>       so accidental reuse in applications where it is inappropriate
>       requires errors on both ends.

The issue is less accidental reuse than joint misconfiguration (e.g.,
bad defaults or bad advice in some Stack Overflow document).

> > 2. The additional cost of multiple tickets seems extraordinarily
> >    small, so I am not at all persuaded that there is enough value in
> >    this use case to justify adding new protocol machinery, even
> >    ignoring point (1) above.
> Postfix has a shared cache (indexed by destination domain+mx host) for
> multiple independent processes racing to use the cache to make remote
> SMTP connections.
> Frequent writes to that cache create measurable overhead and still don't
> prevent reuse.

I'm sorry to say that I'm not that sympathetic to this position. I
appreciate that it's inconvenient for Postfix to have frequent writes
to the ticket cache, but what you propose to do is hoist this
implementation idiosyncracy into the specification, and I don't think
that that's a good tradeoff, both for complexity and because the

> Transmission of unnecessary tickets is also wasteful of
> network and other server resources.

Well, my position here is that these tickets aren't unnecessary,
because you should be using them, rather than violating the
SHOULD in the 8446.

> Erasing tickets on first use would be unwise, most existing servers will
> not presently return a fresh ticket on resumption.

This seems like a defect in those servers. However it can be handled
by not erasing tickets until a new ticket is provided.

> > 3. If there *is* such value, then you can register your own extension
> >    which allows you to say the orthogonal thing, namely "don't send me
> >    any tickets at all if you are resuming". This would be more
> >    flexible in that you could then say "I would like 10 tickets, but
> >    only if you don't resume". Note that
> > would
> >    allow you to do this efficiently.
> This is an interesting idea, but how would the two extensions interact?

I would imagine the logic would be:

If !reuse || !present(reuse extension) {
  send min(max-local-tickets,
           tickets-requested-extension-present ?
           tickets-requested-extension-value :

> And wouldn't that interaction add more complexity?

Perhaps. At least in NSS, I imagine it would be pretty comparable, assuming
we opted to implement the non-reuse one at all.

> By hypothesis
> clients that are willing to reuse tickets don't really need more than
> one at a time. Is there a clear use case for multiple concurrent
> reusable tickets.

Yes, I see your point here. I don't have a clear case for this, but
I'm also not sure that there isn't one: concurrent usage and serial
usage are not necessarily the same.

> > Thus, I would prefer to advance this document as-is.
> Thanks for the substantive response.  Much appreciated.  I hope you're
> willing to address the above reaction, I am trying to find common
> ground that addresses your concerns and mine.

And thank you for your substantive response. I am not sure if we will be
able to
find common ground however.