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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 January 2020 02:14 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 EE487120089 for <tls@ietfa.amsl.com>; Wed, 22 Jan 2020 18:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AIDs-tiDASg4 for <tls@ietfa.amsl.com>; Wed, 22 Jan 2020 18:14:57 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F51212006F for <tls@ietf.org>; Wed, 22 Jan 2020 18:14:56 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 499344ACF6; Wed, 22 Jan 2020 21:14:55 -0500 (EST)
Date: Wed, 22 Jan 2020 21:14:55 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200123021455.GA73491@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com> <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com> <20200121055411.GJ73491@straasha.imrryr.org> <97de6364-c628-45aa-8613-ba1a32cc41b2@www.fastmail.com> <A5448AC9-6EBB-48F9-A1B0-A787FBBCFF05@akamai.com> <08A4B0CD-9903-4027-B672-E8C7AFB34B4D@akamai.com> <20200123005528.GA12073@localhost> <CAN2QdAH7t4fPgBfBSO7Ni1As2bVB9QvCw1s9j0ggqvTRUATE8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAN2QdAH7t4fPgBfBSO7Ni1As2bVB9QvCw1s9j0ggqvTRUATE8A@mail.gmail.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sibxv1xfLzn5Y_nOD_C2aN08rgs>
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: Thu, 23 Jan 2020 02:14:59 -0000

On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote:

> >  - either the TLS server says "here's a ticket and you MUST or MAY
> >    replace the one you already had"
> >
> >    or
> >
> >  - the TLS client gets to ask for no unnecessary new tickets
> >
> > Now the first alternative would be infeasible to adopt because it would
> > require new OpenSSL callback APIs, and anyways would be a more invasive
> > change to TLS than the ticketrequest extension makes.
> 
> Nothing says you have to remember tickets, so unless I'm missing
> something the semantics already are the second one.

I want to use tickets for resumption, so naturally I have to remember
them.  I also don't actually get to directly see the tickets, rather
OpenSSL invokes a "new_session_cb" callback after updating the current
session with newly received tickets.

Since I have a shared cache, I have to perform the work of storing the
updated sesion, so that other SMTP delivery agents get to see the new
ticket.

I can't just ignore the ticket, since the reason for the new ticket may
be that the old one has expired, either after some period of reuse, or
because the server only ever issues single-use tickets.

The deployed base of Postfix servers issues multi-use tickets (always,
there's no extension to tell me otherwise), and sends zero tickets
on resumption, so I need to not just throw away tickets that are
still valid.

-- 
    Viktor.