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

Daniel Migault <> Fri, 06 December 2019 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D0B512085B for <>; Fri, 6 Dec 2019 07:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sAK6yPI5wTQv for <>; Fri, 6 Dec 2019 07:26:30 -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 4A4AD120861 for <>; Fri, 6 Dec 2019 07:26:27 -0800 (PST)
Received: by with SMTP id b79so217172vsd.9 for <>; Fri, 06 Dec 2019 07:26:27 -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=Cl/1dbQmq+5Mr8GM/eDUFtbNf6vWuoVUr+tYPdIxBuU=; b=ESyfcq1DrVTlr7cUs8CWftU1sINRLJkIuHNTwS37URa3OS80B/ln6fSQxdBLlLmE4Y mm1RfQPRTrtoeiOeGXveY3WDxWwtMVc/tZPD5OXPoIclITBb6GYaWGVS9F230XNdXSHi pYIPD6qUL+UVVC8COFLIpf+P2YF5fDYoTQKcrEEpdsnggJ54soRePVdLrTSlW5q+IEIW M8qfCb6JcWIP178HVNK0mLgrVSIkzvnbRt923aeE+kmlf+lOf/JEJkMFXX1ynQOVtIUS r6dHI5RGmgPgt+FIw8pCeLQIv9WtsfQHb6CkFp72MdkvoP0ODl29p8eXWCjDIhmGhipH 9j2Q==
X-Gm-Message-State: APjAAAW+0tkOOkxTUNq2yVCwTV9VPLYwWthBz1T3hZJLQXR0pGtgyexD BBebx33bNueVclrXjmNIfkBJEVYcFK3HuUWbEK4=
X-Google-Smtp-Source: APXvYqwhltLQzcIMLZrVGhYbCpNEqX3e8M2kR7XDnnLTRbPE0oGf8vLFXtiPFBbhAT/CKi9b9ApLCUQUj1g34l8Y/Ew=
X-Received: by 2002:a67:ead6:: with SMTP id s22mr10177243vso.69.1575645986363; Fri, 06 Dec 2019 07:26:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Fri, 6 Dec 2019 10:26:14 -0500
Message-ID: <>
To: David Schinazi <>
Cc: tls <>
Content-Type: multipart/alternative; boundary="0000000000004f212f05990aabdf"
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: Fri, 06 Dec 2019 15:26:33 -0000


Being the last in the queue for a while I realized [1] presents a typo that
may prevent my response to be seen. If that were the case,  in order to
move the document forward, I am re-iterating:

I agree with the proposed text from David. This ends the MUST/SHOULD

I also think we agreed the security consideration should provide some text
related to an amplification attack - when tickets are sent right after the
server Finished. If that helps I believe something around the the following
lines could be added:

In some cases, a server may sent NewSessionTicket immediately upon
sending its Finished rather than waiting for the client Finished. An
attacker may take advantage of this behavior to create an
amplification attack proportional to the count value toward a target
by performing the key exchange over UDP with spoofed packets. The
limit on the number of NewSessionTicket messages sent in response to a
"ticket_request"  MUST be based on the applicability and the
amplification factor of such attack.


The remaining discussion in the list seems related to Viktor proposal,
which I think would greatly improve the document.



On Mon, Nov 25, 2019 at 12:04 PM Daniel Migault <>

> On Wed, Nov 20, 2019 at 10:20 PM 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:
>> 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