Subject: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt

From: Chris Wood <[email-masked]>
Date: Thu, 12 Apr 2018 20:15:42 -0700

Hi everyone,

Below is a pointer to a new I-D describing an approach for clients to request session tickets via a new post-handshake message. This is useful for applications that perform parallel connection establishment and racing, e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses and details are given in the document. 

We would very much appreciate feedback on the mechanism utility and design.

Best,
Chris 

Begin forwarded message:

> From: [email-masked]
> Date: April 12, 2018 at 8:07:35 PM PDT
> To: David Schinazi <[email-masked]>, Christopher Wood <[email-masked]>, Tommy Pauly <[email-masked]>, "Christopher A. Wood" <[email-masked]>
> Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt
> 
> 
> A new version of I-D, draft-wood-tls-ticketrequests-00.txt
> has been successfully submitted by Christopher A. Wood and posted to the
> IETF repository.
> 
> Name:        draft-wood-tls-ticketrequests
> Revision:    00
> Title:        TLS Ticket Requests
> Document date:    2018-04-12
> Group:        Individual Submission
> Pages:        6
> URL:            https://www.ietf.org/internet-drafts/draft-wood-tls-ticketrequests-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/
> Htmlized:       https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests
> 
> 
> Abstract:
>   TLS session tickets enable stateless connection resumption for
>   clients without server-side per-client state.  Servers vend session
>   tickets to clients, at their discretion, upon connection
>   establishment.  Clients store and use tickets when resuming future
>   connections.  Moreover, clients should use tickets at most once for
>   session resumption, especially if such keying material protects early
>   application data.  Single-use tickets bound the number of parallel
>   connections a client may initiate by the number of tickets received
>   from a given server.  To address this limitation, this document
>   describes a mechanism by which clients may request tickets as needed
>   during a connection.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 13:49:26 +1000

Hi Chris,

Thanks for sharing this.  It's a simple idea and seems generally useful.

Do you have a use for the identifier and context?  I can see that
without them there is no way to distinguish between a response to a
request and spontaneous ticket issuance, but I just can't see how that
is a problem.

I think that you want an extension for this.  Otherwise, the server is
going to explode when it sees a TicketRequest message.

If you have an extension, then negotiating that extension might be
used suppress spontaneous ticket issuance.  That has a catch though:
then a server can't issue new tickets that bind to updated state (such
as might happen after a connection migration in QUIC).  I don't know
how much people care about that trade-off.

Sorry I didn't catch these before.

Cheers,
Martin

On Fri, Apr 13, 2018 at 1:15 PM, Chris Wood <[email-masked]> wrote:
> Hi everyone,
>
> Below is a pointer to a new I-D describing an approach for clients to
> request session tickets via a new post-handshake message. This is useful for
> applications that perform parallel connection establishment and racing,
> e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses
> and details are given in the document.
>
> To: David Schinazi <[email-masked]>, Christopher Wood
> <[email-masked]>, Tommy Pauly <[email-masked]>, "Christopher A. Wood"
> <[email-masked]>
> URL:
> https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests
>
>
> Abstract:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 13:53:37 +1000

Scrub the bit about needing the extension.  I read past Section 4
completely.  The other comments are still relevant.

---

From: Christopher Wood <[email-masked]>
Date: Thu, 12 Apr 2018 20:55:43 -0700

Hi Martin,

Please see inline below.

> On Apr 12, 2018, at 8:53 PM, Martin Thomson <[email-masked]> wrote:
> 

No problem.

>> request and spontaneous ticket issuance, but I just can't see how that

Yes — we’re currently working on an I-D that would use the context for “special” tickets. Depending on where that goes, if anywhere, we may or may not need to keep the context. As you suggest, distinguishing between responses and spurious NSTs doesn’t *seem* like a problem.

Best,
Chris

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 14:07:55 +1000

> Yes — we’re currently working on an I-D that would use the context for “special” tickets. Depending on where that goes, if anywhere, we may or may not need to keep the context. As you suggest, dist…

Maybe the right way to deal with this is to put an extensions block in
the request.  Then you only have to resolve the question of whether
NST answers the ClientHello or this new message...

---

From: Christopher Wood <[email-masked]>
Date: Thu, 12 Apr 2018 21:14:06 -0700

> On Apr 12, 2018, at 9:07 PM, Martin Thomson <[email-masked]> wrote:
> 
> NST answers the ClientHello or this new message...’

Indeed. That might work just as well, if not better. 

In any case, as written right now, we prohibit servers from sending spurious NSTs if both parties negotiate request support. If implementations honor that requirement, we won’t have a distinguishing problem. We then need only decide what is the best encoding strategy for request identity/context, if desired.