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

Tommy Pauly <tpauly@apple.com> Sun, 02 February 2020 14:43 UTC

Return-Path: <tpauly@apple.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 A1987120100 for <tls@ietfa.amsl.com>; Sun, 2 Feb 2020 06:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=apple.com
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 gHeAhnoara79 for <tls@ietfa.amsl.com>; Sun, 2 Feb 2020 06:43:07 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC0312006E for <tls@ietf.org>; Sun, 2 Feb 2020 06:43:07 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 012EflOZ063451 for <tls@ietf.org>; Sun, 2 Feb 2020 06:43:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : in-reply-to : to; s=20180706; bh=aOUVjgfF5huFOaqOpwsy3zQqGa82An6KXfcGKJ6LMVk=; b=RmjpCiEbv9OUMGADxRuPcL7V0fQPxRUc5JkeAu6WxfrXnEXywAeVbz0aA5z/8qk3Xvn/ BRAWIwN8HW5THeGSmM2D3ADDJd3HMXpS73724Wmqo2F80jIoe4L6D3UabL8n0FdgOW0u WsZunKyX2iUFi5iq8VOdYbwZcbEq9PJ9xJtz3kONbGaYTNljDvUisZqXDiZIMoUtEI7d hJdb/1jaQUD3CHrDeu2rKuaTxMl7UG7WxtXm/aEoRUompfmndcQVyyPgMY0p+4E3mWgR jCfA/BTNzaMAS2cIDv5LJdcAiVaoqHvqxyWUx0C/X6NYmWrwM1WrlqbNxJcsQWN4kJm+ AQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2xw970112f-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <tls@ietf.org>; Sun, 02 Feb 2020 06:43:06 -0800
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q52002N7WVLYE70@rn-mailsvcp-mta-lapp03.rno.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 06:42:57 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5200900U3AN900@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 06:42:57 -0800 (PST)
X-Va-A:
X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: 78f997bc-b601-4b77-b07b-3b3da0e2445a
X-V-A:
X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: 0311abb0-e01a-4dd7-90d3-7d9bb157c4af
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-02_04:,, signatures=0
Received: from [17.234.105.142] (unknown [17.234.105.142]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q5200MB5WVLJ160@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Sun, 02 Feb 2020 06:42:57 -0800 (PST)
Sender: tpauly@apple.com
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
From: Tommy Pauly <tpauly@apple.com>
MIME-version: 1.0 (1.0)
Date: Sun, 02 Feb 2020 06:42:56 -0800
Message-id: <1DEFB79F-802A-452C-8AE3-41336AC58F25@apple.com>
References: <20200202115203.GK49778@straasha.imrryr.org>
In-reply-to: <20200202115203.GK49778@straasha.imrryr.org>
To: tls@ietf.org
X-Mailer: iPhone Mail (18A214)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-02_04:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0-2KVuGdKR4ZMYEOLmxPbrZVz7I>
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: Sun, 02 Feb 2020 14:43:09 -0000


> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote:
> 
>>> Sorry, no idea what that above means.  And is it simpler than the
>>> proposal under discussion (which got some fine-tuning in early
>>> feedback)?
>> 
>> So one proposal in above is we treat 0 tickets as "ensure I have a valid
>> ticket, either this one or a new one" and all other numbers are straight
>> asks for that many tickets.
> 
> This is indeed simpler, but it removes the ability to ask for zero
> tickets, which I think was one of the intended use-cases (that's what
> the 255 is for).
> 
>> The other proposal is N means "ensure I have N valid tickets, including the
>> one I used on this connection". I find both cleaner then the 0 and 255 swap.
> 
> The problem here is now reuse is implicit, and the only way for a client
> to ensure that it gets a fresh ticket, is by asking for 2.
> 
> So I now see where you're coming from, and it was worth a try at
> simplification, but I don't think it works out.  The reasons for
> two sentinels is that in fact are three separate cases.
> 
>    1.  Client wants no tickets
>    2.  Client wants to try to reuse an existing ticket
>    3.  Client wants n > 0 fresh tickets.
> 
> I don't see how to handle 1 and 2 cleanly without two sentinels.

I think Watson’s point (which I fully agree with) is that sending the value “0” already means “the client wants no tickets”.  The document already explains this usage. Thus, you don’t need a sentinel value to express that case—is what the value of N already intuitively means. 

If you did need a sentinel to indicate that you wanted to try to reuse a ticket (which you can always try if you want), it would make more sense to just make that sentinel be 255, etc, rather than creating two sentinels.

The ticket reuse signaling that is proposed really is orthogonal to the *count* of tickets.

When requesting a number of tickets, there is a signal in one direction from the client about how many tickets it wants; and the server signals back by issuing some number of tickets. There isn’t much ambiguity.

On the other hand, the proposed sentinel value indicates “I’d like to reuse tickets if I can”, but without any additional signaling from the server about the support of ticket reuse, a server response containing no tickets is ambiguous—maybe it means ticket reuse is fine; maybe it means the server isn’t giving out any more tickets and won’t allow resumption. It is much clearer if there is a bidirectional signal about negotiating ticket reuse.

Beyond that, it seems odd to mark a Boolean sent by the client to ask for ticket reuse in an integer that counts numbers of tickets. It’s not that one value (255) is precious, but it means that these orthogonal concepts can no longer be communicated separately. Let’s imagine a client that had received 4 tickets the first time around, on request, and then wanted to either reuse some of them or ask for 2 more. Keeping the ticket request just a number and having a separate message for the reuse Boolean allows that. Allocating a sentinel means that a request for reuse to a server that doesn’t support reuse now loses the ability to request a particular number of tickets.

Thanks,
Tommy

> 
> -- 
>    Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls