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

Daniel Migault <> Mon, 25 November 2019 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B679120813 for <>; Mon, 25 Nov 2019 09:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PVZux9jpHsC4 for <>; Mon, 25 Nov 2019 09:05:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D35812099A for <>; Mon, 25 Nov 2019 09:05:06 -0800 (PST)
Received: by with SMTP id d6so1712609uam.11 for <>; Mon, 25 Nov 2019 09:05:06 -0800 (PST)
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:cc; bh=BFY/Xq3axOQkmRxVM9GOoQ5/KnqqhzAe5lTMh5YymdE=; b=LjbjSSoWHi+MAD5juCDx3p84Qd3VAJPtS1RdizD5M4BmFIPf0fyMJ/YJeZ4tLKVo5R 0N1y4Bfkq3loaKcafT+RtJdg4A4CbcALmQi9KvOirysMvt7JwAhfBP2yuTl+iAOpYXwr uVzQk9ZTQ3y5GbJlzti+A9fvr49i0SAJNQ7gAaUfqF39UgTaMuqGsA4YFExT65YjFfcv Yi1tIZphPz6MNhbAUCGzFOnigi8rxMhP5n49Da+etdBNkDA7nl+NONi593yUX1LX/nin vTzzmKZpMq2f+I+fTSVksZRWxjD80Z34o6TMy09fqsw5zzRCG102uaGelqIqidAW6fXS YgXw==
X-Gm-Message-State: APjAAAUNO1qZmbuOi4m8oy/qD5W05KzFN8aYdTbPlC8Lq71qr2Cnpx3n LPkTHAnlJYJdn//LhiaWEPCGBOI/CkxB1p8YPYhujg==
X-Google-Smtp-Source: APXvYqwNfcTnncOLMriZeyjVmyyeL5Kui6ekdfDWY8ABG2H9+DFMpI3PTGanT/RQwG5kHJe0eNnJJQ1leUu53d91EvI=
X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr18379535uag.114.1574701505623; Mon, 25 Nov 2019 09:05:05 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Mon, 25 Nov 2019 12:04:54 -0500
Message-ID: <>
To: David Schinazi <>
Cc: tls <>
Content-Type: multipart/alternative; boundary="000000000000debabf05982ec346"
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: Mon, 25 Nov 2019 17:05:08 -0000

On Wed, Nov 20, 2019 at 10:20 PM David Schinazi <>

> 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:
> 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.
> I apology for the late response. This addresses my MUST/SHOULD concern.
Thanks David.

> 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 particularly like the proposal from Viktor and - at least as I see it -
its associated simplicity. I believe it would be beneficial for the
document to include it.

> Thanks,
> David
> On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni <>
> 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 mailing list