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

Daniel Migault <daniel.migault@ericsson.com> Wed, 22 January 2020 01:32 UTC

Return-Path: <mglt.ietf@gmail.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 819FF12002F for <tls@ietfa.amsl.com>; Tue, 21 Jan 2020 17:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 2HvQS39azCJJ for <tls@ietfa.amsl.com>; Tue, 21 Jan 2020 17:32:34 -0800 (PST)
Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 51079120013 for <tls@ietf.org>; Tue, 21 Jan 2020 17:32:34 -0800 (PST)
Received: by mail-ua1-f49.google.com with SMTP id 73so1821117uac.6 for <tls@ietf.org>; Tue, 21 Jan 2020 17:32:34 -0800 (PST)
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:cc; bh=fdxLi7klJ9IGQbcvGeP0suUHvESG+Yh2aNVg08W5Uhg=; b=bm22jtNTyWqUjLZvjqLtEgADXonO4hbA7wihPQBMKGRGbjWgpw8q1omMuYg96t+5yO +POFpPPt8B4ZjqubuG+romCtubMD4nGaT1VbIR+WmWYtioJoHv58oickC8ErGAupFRA8 N3LSUp++GbXyFLN5W5oF95JmxJ0qXufiDn9a4ascA7Eif0RQ8sqTgKdOOPWxfjiPkicn u7jMYBbOMWorDv189kayraOaIb7hAjCpTgZv4takFjk/FGua5SfLx6JMVP9rG8zL9KC8 EYrY+o7EGz1/xfsQU7RqKvIgWh4OrZJJfEBXZNg9DZAaOAnv9fOjiFxcfkKmUc0ywk8l q5Og==
X-Gm-Message-State: APjAAAU4YvrxjeXECiGQUWhEaEMkCFExT2uMSpwfMTSf9Q0o/1ThkI8M H1txzYkCmIFips8DKGaMpsi1Q9GcbBj7mRYsIydNKhtGIpLxiw==
X-Google-Smtp-Source: APXvYqyU335Tu8vkrE8xMUyh2n7lPhJmZHI7W7V2g6QdlqBIWbW0NN6dqmoqJX1DPsCegPRtwTz2kYXRagY+0864X9Y=
X-Received: by 2002:ab0:6881:: with SMTP id t1mr4815969uar.88.1579656753330; Tue, 21 Jan 2020 17:32:33 -0800 (PST)
MIME-Version: 1.0
References: <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <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>
In-Reply-To: <CABcZeBP=BetaxVo5v-khdykP0U3P6j-e+hL307o8Wn3KC9rmhA@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 21 Jan 2020 20:32:20 -0500
Message-ID: <CADZyTknofeojf16DUCqb_FuhDkj48z_O+BYW+PjLb0dLLej4rg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a63c1e059cb07f5d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ikUv7NX86P0SarcPt1n_SCwcP6M>
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: Wed, 22 Jan 2020 01:32:37 -0000

I support the proposal from Viktor. It is important to minimize the
involved resource and provide the client the ability to explicitly inform
the server its policy.

As explained above, this mechanism comes with no additional complexity and
address a full range of applications.

See below my comments inline:

Yours,
Daniel
On Tue, Jan 21, 2020 at 4:19 PM Eric Rescorla <ekr@rtfm.com>; 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.
>

 Appendix C.4 discourages the re-use of tickets to avoid passive
monitoring. This recommendation only applies when privacy is involved, and
other use cases exist (VNF, IoT, MTA,...). This is not *potentially* true,
this is simply true. These use cases are considered by RFC8446 and thus
need be considered in this proposal.

>
> 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.
>
>
As explained before, the *machinery* is also largely exaggerated. Those for
who the cost of generating ticket is so extraordinarily small actually do
not need this extension and can generate an extra large number of tickets
(at no cost for them).  This statement seems to contradict at least the
Less ticket waste use case.  In addition, saving cost per connection scales
the number of connections which is not negligible.

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

It is unclear to me why, in this case, this would apply specially to
Viktor's proposal rather the counter proposal.


>
> Thus, I would prefer to advance this document as-is.
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jan 20, 2020 at 9:54 PM Viktor Dukhovni <ietf-dane@dukhovni.org>;
> wrote:
>
>> On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote:
>>
>> > On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
>> > > Regarding Viktor's suggestion, I personally believe it would increase
>> the
>> > > complexity of the proposal, and I don't see use-cases compelling
>> enough
>> > > to warrant that complexity. I would rather keep this proposal as
>> simple as
>> > > possible.
>> >
>> > I see that I didn't respond to this.  I support David's view.
>> >
>> > Even the suggestion that clients that resume only request one assumes
>> > that clients only want one.  The client probably knows better than we
>> > do.  I would rather say nothing about the number and keep it simple. 0
>> > means 0, 1 means 1, N means N.
>>
>> The proposal has since been simplified. With 1 meaning 1, 2 meaning 2,
>> .....  The only change is that 0 and 255 become special, with 255 meaning
>> definitely no tickets, and 0 meaning tickets only if the server sees a
>> need a replace the presented ticket.  Otherwise, the client has no way
>> to request refresh only if needed, and must ask for 1 just in case.
>>
>> Unnecessary tickets are a waste server and client resources and
>> bandwidth, and make external caches "hot" on clients that are perfectly
>> fine with a slowly changing series of multi-use tickets.
>>
>>
>> > FWIW, the cost of oversupply is often marginal, depending on
>> > circumstances.  In a client-speaks-first protocol with no client
>> > certificate, the server can occupy the first round trip with tickets
>> > and generally gain a performance advantage (as sending more will
>> > increase the congestion window in most cases).
>>
>> This is useless for clients with just a single mult-use slot in their
>> ticket cache.  Not everything is a web browser.
>>
>> > Otherwise, there are usually quiescent periods that can be exploited
>> > for sending tickets.  And tickets are small, and cheap to generate.
>> > With one exception: if you are relying on client authentication and
>> > packing that into tickets, I'm sorry.
>>
>> 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, ...).
>>
>> --
>>     Viktor.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>