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

"Christopher Wood" <caw@heapingbits.net> Thu, 21 November 2019 05:34 UTC

Return-Path: <caw@heapingbits.net>
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 CA7D7120044 for <tls@ietfa.amsl.com>; Wed, 20 Nov 2019 21:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=heapingbits.net header.b=tqMMwR9n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=btl08Wgt
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 j7MysijQAAWD for <tls@ietfa.amsl.com>; Wed, 20 Nov 2019 21:34:28 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B864F120143 for <tls@ietf.org>; Wed, 20 Nov 2019 21:34:28 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EB26D22431 for <tls@ietf.org>; Thu, 21 Nov 2019 00:34:27 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 00:34:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=uaXMjcERZ7QVXKO6jGas9tKGTxp7DZ+ ykWLTbRNQt88=; b=tqMMwR9ncuqucLJdpqyVwS9x+120glAvOtiU3EX/zANqE33 WN57O8VtHWjsoOWTZAQOVN8escz/X17spnzGJKpk/AHN0NFxuwxwY09bIorbQfZL GHr+UTtWxeKX4QyuKuJuwIJISFZQ9vv2kW1UxiF5dnXIOOFY2bWyY8EHe4twnlzN MikA/nXeokYQW1FwA5CLMS8bmq0mlwrc+rABHgMes/ZJwg/tIqAcr+fJJa/w+dhZ dWmyHuV/09f6GwksXlcU7z5KHCyZZm5msxXeUfcuvM954naJbbDoF+z79QQAyMjB p5+nBBbw2N2BtKDK7Tazxuz1lJSQGWuYhJ229BQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=uaXMjc ERZ7QVXKO6jGas9tKGTxp7DZ+ykWLTbRNQt88=; b=btl08WgtgQAJUcRd1PrazT mxQg+oTcC8plOw6qn5vOOCrxGtfxUMhiVn7r4J2FGBJ1OJ3mJ17zzN+V+n2CQWRB XqFP8Bv3H3dV2+TJvh3dbYzx+fyDsk+DbKUwHNgSXWjijFVMePJLQ08vl3KD2lcC eRym9pXJzT/lMu4bUY0iskcujqrLNEBO5ixc1YWWAKwLtxaA2Hiz3wqya6vXOhdb BFN9jEYFUt8+edGGl9JiVHobQVzKkfIo4cbTJL4DkqFQFUsnflNjrWPB7KhGe61c Ze7zAk0d3qizGW8HhDUpG0z8rmA7FwyBMExZPHiN9wBKLD5rg7aI7pCYmLNy98cA ==
X-ME-Sender: <xms:4yHWXbx4MdNE9jYTFJ03qd1rOE-H-iEvFohuGfqa37n5iTx49dgPUA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:4yHWXS8SVD3YXw1f16-TtMdl49uVYv2vvjQ30I-be8t82q-pPgxt4g> <xmx:4yHWXQ9-7oydbEULwxoxxqs1Qtv_A1L5u9FGwm9MNk-1VLv1esazag> <xmx:4yHWXRVq73VbUfMuF6BSrb8l70OXAzgPfBuRwUVkKq-1YtOuq4Xamw> <xmx:4yHWXQWyG6Ups5LvJ5UX6zswq56oeDVir1Kg7P1SEkKVBPALTKWDHg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id ABF7B3C00A2; Thu, 21 Nov 2019 00:34:27 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: <1fe837a5-a32a-44c4-be7d-7da480f6b9f4@www.fastmail.com>
In-Reply-To: <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com>
References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <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>
Date: Thu, 21 Nov 2019 13:34:07 +0800
From: "Christopher Wood" <caw@heapingbits.net>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/l1uNWhvoKoQUGCgI5R1CtlFy3hQ>
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: Thu, 21 Nov 2019 05:34:31 -0000

Thanks for clarifying, David! This text reflects my understanding and is fine by my. 

Best,
Chris

On Thu, Nov 21, 2019, at 11:19 AM, David Schinazi wrote:
> Hi folks,
> 
> I've chatted with Daniel and Chris offline, and I think there might
> have been some miscommunication here. Please allow me to
> rephrase what I think is going on, and please let me know if
> this accurately represents your views.
> 
> Daniel has a IoT use-case where due to memory constraints,
> a client knows it can only handle a certain number of tickets,
> and therefore Daniel was wondering if it would make sense to
> make the requested number of tickets a required maximum
> (as in a RFC 2119 MUST). However, server operators on this
> thread have indicated that a MUST would get in the way of
> implementing this, due to STEK rotation for example. Daniel
> understands this, and is OK with the current mindset of the
> document (which is only a hint, not a MUST). Additionally,
> Daniel would prefer to see the document move forward.
> 
> In order to try to address Daniel's comments, I attempted
> to rephrase the normative section to suggest in more
> stronger terms that servers really shouldn't be sending
> more than the client's request, but keeping it a SHOULD.
> 
> Here is the PR with the rephrase:
> https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10
> 
> Here's a copy of the updated paragraph in the PR:
>  Clients can use TicketRequestContents.count to indicate the number of
>  tickets they would prefer to receive. Servers SHOULD NOT send more
>  tickets than TicketRequestContents.count, as clients will most likely
>  discard any additional tickets. Servers SHOULD additionally place a
>  limit on the number of tickets they are willing to send to save
>  resources. Therefore, the number of NewSessionTicket messages sent
>  SHOULD be the minimum of the server's self-imposed limit and
>  TicketRequestContents.count.
> 
> 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.
> 
> Thanks,
> David
> 
> 
> On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> > On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote:
> > 
> >  > > Somebody should try to avoid ending up with N new tickets after
> >  > > every connection, but in could well be the client.
> >  > 
> >  > Yes, I think that can and ought to be the client. The client is really the
> >  > only party that can know how many tickets have been "consumed" by potentially
> >  > failed attempts to connect that the server didn't see in time or got dropped.
> > 
> >  OK, in that case, the proposal, is that on resumption, if the proposed
> >  extension is *absent*, then the server should generally send just one rather
> >  than any larger default.
> > 
> >  If the extension is present, it is up to the client to not blindly ask for N
> >  tickets each time, and generally ask for just one ticket on resumption, once it
> >  has sufficiently many tickets for the desired concurrency level, with each
> >  parallel thread obtaining one replacement ticket its next connection.
> > 
> >  As discussed clients that prefer to reuse tickets, can ask for zero, and get 1
> >  only as-needed. If the server supports reuse then all is well.
> > 
> >  If the server does not support and refuses reuse, then it will issue a new
> >  ticket each time and may only accept it once, but the client may have a
> >  single-slot cache. If the client makes only one connection at a time, this
> >  also works, but if/when its handshakes with the server overlap (a narrow window
> >  of ~1RTT) and two connections attempt to resume with the same ticket, one of
> >  them will end up doing a full handshake, but only when the client and server
> >  applications have incompatible ticket reuse expectations. Some friction
> >  when the client and server are mismatched is not the end of the world.
> > 
> >  So on the whole I think the proposal still works with just a numeric signal
> >  (tweaked with 0xff == none and 0 == reuse), and the onus to "generally send 1"
> >  on resumption moved to the client (i.e. clients that don't solicit ticket reuse
> >  should request only 1 ticket once they have enough).
> > 
> >  -- 
> >  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
>