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

Tommy Pauly <> Sat, 01 February 2020 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D2FA12013C for <>; Sat, 1 Feb 2020 07:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GNIGjqd1vpQq for <>; Sat, 1 Feb 2020 07:54:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A15B120804 for <>; Sat, 1 Feb 2020 07:54:02 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 011FkoU0018692; Sat, 1 Feb 2020 07:53:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : content-type : content-transfer-encoding : mime-version : subject : from : in-reply-to : cc : date : message-id : references : to; s=20180706; bh=fJflOe4ygqzU1MsTgImeQAXfRRzbnOEkYUMQIfkTgbE=; b=tIPx0AdQNmt/72j2QnYhmlCpDydPE1qsVI/Qb5NZEH8oRporTIt1blkFlkcRhiJiokaJ 7oq80KqbgvXoewwx2mfw0JcwNHkBUdTiaRXWvsJyc86csJO8bvi553QbtjHigoJdBkjr eD4m+jX9YWNL6oGVQYK8M8jpXQGxKNaeOGom4TG1EO36t/x/Wd88zGaX4Lo3BY7qA34X MmqaVFu0cYwYs88rIQXb9M22NKfJjs350FCoeIXyFFLdUJiuoZJMDKMujSlb8gSj1Qx/ YW0s0E1iBIJG/ksCu4dFN+F/nKZQLZQXGUFtwEbQMGFvwMosEaN7nfgle+A4Rnf0a/CT xw==
Received: from ( []) by with ESMTP id 2xw8v6cwmg-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 01 Feb 2020 07:53:59 -0800
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Jul 4 2019)) with ESMTPS id <>; Sat, 01 Feb 2020 07:53:58 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <>; Sat, 01 Feb 2020 07:53:58 -0800 (PST)
X-Va-T-CD: b885964abc53914bb4dc9f6410fd4b52
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: 2d842721-cd26-49b0-8f9b-be06441e0a93
X-V-T-CD: b885964abc53914bb4dc9f6410fd4b52
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: 81144eaf-ac28-4419-89ab-b75959aebb71
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-01_03:,, signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <>; Sat, 01 Feb 2020 07:53:58 -0800 (PST)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (1.0)
From: Tommy Pauly <>
In-reply-to: <>
Date: Sat, 01 Feb 2020 07:53:57 -0800
Message-id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: iPhone Mail (18A214)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-01_03:, , signatures=0
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: Sat, 01 Feb 2020 15:54:06 -0000

> On Jan 31, 2020, at 6:14 PM, Stephen Farrell <> wrote:
> Hiya,
> I have no particular position about this draft but
> am curious about 2 things:
> #1 I don't get why it's not possible for postfix to
> determine the best way to manage tickets based on the
> destination port to which the ClientHello is sent. I
> totally get why that won't solve 100% of cases, but it
> would surely solve a huge percentage? Apologies if an
> answer was already posted as part of this v. long
> thread.
> #2 I don't get why Viktor's request for special handling
> for value 255 is a real problem for anyone. We have
> another thread today envisaging 2040 extensions flags,
> so I really have a hard time seeing what here justifies
> rejecting Viktor's argument. FWIW, this thread has not
> provided me with an obvious answer to #2 other than "not-
> invented-here." I'm not sure that declaring things in the
> rough where the only identifiable issue is NIH is the
> overall best outcome, longer term.

That’s a fair point, and worth clarifying. Totally agree that NIH isn’t a good reason. Instead, it seems unclear what value the special use of 0 and 255 adds that wouldn’t be better served by a separate extension.

Today, without any sentinel values, 0 means the client hints that it doesn’t need any tickets, and N means that the client hints that it would like N tickets. Whether or not a ticket is intended to be reused is not part of this, and ticket reuse is elsewhere discouraged.

As far as I understand the proposal, the meaning currently expressed by sending 0 would be expressed by sending 255 instead; and sending 0 would take on a new meaning that is “send a ticket if you want, and I may try to reuse a ticket if you don’t send one”, which seems like the behavior already expressed by not sending the ticket request message at all (since not passing the message is equivalent to no hint).

To that end, the proposed change doesn’t seem to add any new signaling capabilities, but makes the meanings of numbers less intuitive.

If the hint is intended to be “I’m planning on reusing tickets, let me know ahead of time if I shouldn’t”, that seems like it could be an explicit signal sent that doesn’t need to reuse a field that is a numeric count of tickets being requested. It seems like there is a small number of clients that would use this, so adding another message to signal this and potentially more info about reuse policy would make more sense and could be fleshed out in more detail separately. For example, if we add the proposed hint that presumably means “if you give me a new ticket, I’ll use it; but if you don’t, I’ll reuse an old one”, the client is essentially forcing a server that doesn’t want ticket reuse to issue a new ticket; whereas a more explicit signal could indicate that the server won’t allow ticket reuse, so the client shouldn’t even try, etc, without necessarily giving out new tickets. 


> Cheers,
> S.
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> TLS mailing list