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

Tommy Pauly <tpauly@apple.com> Wed, 20 November 2019 02:40 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 43048120220 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 18:40:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hJg6jhPKH42Z for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 18:40:38 -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 920D41201E0 for <tls@ietf.org>; Tue, 19 Nov 2019 18:40:38 -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 xAK2WKL3014863; Tue, 19 Nov 2019 18:40:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=h1YJUCykqHBRCu/rtSfRGwPf39WpOGIny/y99WoGKyY=; b=kcB2p86o4sHHaYwc7bH1VVb/DiPROcGoXDr8JxraOu7TqzW7rAyNoOpYrrBKFbd4U4/s aJsvZLCTLszLjmiBqiwlR0UbBH8S/IIDMGgo3n61YXfizwOqTCptsHY8gbHtq1wJ9Elj GGNGzfegwivvK27bgyCz13kVzpGhX+q5WOdp4fEBv9wKiPxsbwVUWW+cqEtsX2ko8eT9 12uc/cTf+47LNhCq9hpU+b0e4BPeshX5x6Vhtew3QvXqdl9cmn8qNkJqrE7rDP1MaHN0 frXBTJqV7Amh5pJsbXzIo4V/Gu4tW7mCyaF1uDSxekKYT6wnsrDeKanE8+wALBa+F+mN 9w==
Received: from sg3-postinop-sz01.asia.apple.com (sg3-postinop-sz01.asia.apple.com [17.84.80.96]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2wagyykm4x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Nov 2019 18:40:35 -0800
Received: from sng-mmpp-sz01.asia.apple.com (sng-mmpp-sz01.asia.apple.com [17.84.80.62]) by sg3-postinop-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1800LO7Y3LF000@sg3-postinop-sz01.asia.apple.com>; Wed, 20 Nov 2019 10:40:33 +0800 (+08)
Received: from process_milters-daemon.sng-mmpp-sz01.asia.apple.com by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1800D00VMCYJ00@sng-mmpp-sz01.asia.apple.com>; Wed, 20 Nov 2019 10:40:33 +0800 (+08)
X-Va-A:
X-Va-T-CD: ae695c802e0d396617b4b2b2108e7c6a
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: 0f31403d-b657-4504-84a6-95cf2f09a7e9
X-V-A:
X-V-T-CD: ae695c802e0d396617b4b2b2108e7c6a
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: 7b958fb2-e44f-4169-a178-618c64a59bce
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-19_08:,, signatures=0
Received: from [17.235.155.28] by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q1800MHIY3DVP80@sng-mmpp-sz01.asia.apple.com>; Wed, 20 Nov 2019 10:40:28 +0800 (+08)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_5F98897B-09E2-4B9A-9863-380306F7FCF8"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Wed, 20 Nov 2019 10:40:20 +0800
In-reply-to: <CADZyTkmaUVj=sFdgg93MuM2au0B=1M1k3yCA1XDoaAneVDmnNw@mail.gmail.com>
Cc: tls <tls@ietf.org>
To: Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <caa6f6b4-537c-46bb-a04b-28d2b59f8ecd@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <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>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HQkAbFXE41ChumfiABJNBgjsTGo>
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: Wed, 20 Nov 2019 02:40:40 -0000


> On Nov 19, 2019, at 5:20 PM, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>; wrote:
> 
> Hi, 
> 
> Just to followup the discussion. I support Viktor,'s proposal as it provides the ability to the client to specify what it wants rather than let the server guess. What I am wondering is whether we are catching all possible client "policies" or whether we should consider some additional reserved values. Typically I do not see case where 200 tickets may be requested, so we may have some place for reserved bits if needed. 
> 
> I see my comment of how tickets are generated as complementary.
> 
> Yours, 
> Daniel
> 
> 
> 
> On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni <ietf-dane@dukhovni..org <mailto:ietf-dane@dukhovni.org>> wrote:
> On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote:
> 
> > > That also works, effectively treat 0xff as "-1", but all other
> > > values as non-negative, with 0 a request for re-use.  An isomorphic
> > > encoding, but without the "-1".
> > 
> > [Jeremy had a more eloquent description of the vague sketch of an idea that I had in my head]
> 
> Jeremy's "isomorphic" encoding works fine for me, and is likely less confusing.
> So, FWIW, it has my support.  Fleshing it out a bit more, I am proposing:
> 
>     - 0xff => send no tickets
> 
>     - 0x00 => reuse requested:
>         + send no tickets if presented ticket is accepted and reusable
>         + send one ticket if presented ticket is accepted, but is not reusable
>           (expired, or reuse is not allowed).
>         + Also send one ticket if session could not be resumed and a full
>           handshake was performed.  Clients that reuse tickets don't need a
>           separate one for each session, so one per full handshake should
>           suffice.
> 
>     - 0x01-0xfe => client wants single-use tickets:
>         + send up to that many tickets on full handshake,
>         + however, generally send just 1 ticket on resumption, or when
>           replacing tickets during long-lived connections.  This helps to
>           reduce chronic ticket "oversupply".

Having a recommendation to generally just send one ticket doesn't address the motivating use case for the document, which is Happy Eyeballs (connection racing). Having multiple tickets is required in a steady state, so we shouldn't recommend against that.

Any client that wants to only do the reuse case can just not use this extension.

Thanks,
Tommy
> 
> -- 
>     Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls