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

Eric Rescorla <ekr@rtfm.com> Sun, 02 February 2020 17:08 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D92120241 for <tls@ietfa.amsl.com>; Sun, 2 Feb 2020 09:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCWHguVfMlSu for <tls@ietfa.amsl.com>; Sun, 2 Feb 2020 09:08:56 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B614912004D for <tls@ietf.org>; Sun, 2 Feb 2020 09:08:55 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id h23so12138755ljc.8 for <tls@ietf.org>; Sun, 02 Feb 2020 09:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <20191117002249.GV34850@straasha.imrryr.org> <CADZyTkmaUVj=sFdgg93MuM2au0B=1M1k3yCA1XDoaAneVDmnNw@mail.gmail.com> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com> <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com> <20200121055411.GJ73491@straasha.imrryr.org> <CABcZeBP=BetaxVo5v-khdykP0U3P6j-e+hL307o8Wn3KC9rmhA@mail.gmail.com> <20200121224610.GR73491@straasha.imrryr.org>
In-Reply-To: <20200121224610.GR73491@straasha.imrryr.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 2 Feb 2020 09:08:17 -0800
Message-ID: <CABcZeBOq+mvY4mx+VT0QB08b67noqZyvr0NE-_YMGsz5VoSDuA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000082ac97059d9adc50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ef7AnhShZ0QaYmIYAALeC-lrojk>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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
> >    (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). 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
   extension.

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
> >    https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ 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 :
           1)
}

> 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.


-Ekr