Subject: [TLS] I-D Action: draft-ietf-tls-ticketrequests-01.txt

From: [email-masked]
Date: Thu, 06 Jun 2019 16:47:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : TLS Ticket Requests
        Authors         : Tommy Pauly
                          David Schinazi
                          Christopher A. Wood
	Filename        : draft-ietf-tls-ticketrequests-01.txt
	Pages           : 6
	Date            : 2019-06-06

Abstract:
   TLS session tickets enable stateless connection resumption for
   clients without server-side, per-client state.  Servers vend an
   arbitrary number of session tickets to clients, at their discretion,
   upon connection establishment.  Clients store and use tickets when
   resuming future connections.  This document describes a mechanism by
   which clients may specify the desired number of tickets needed for
   future connections.  This extension aims to provide a means for
   servers to determine the number of tickets to generate in order to
   reduce ticket waste, while simultaneously priming clients for future
   connection attempts.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-01
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Hubert Kario <[email-masked]>
Date: Fri, 07 Jun 2019 13:36:43 +0200

>    number of tickets vended per connection.  Second, clients do not have

>    NewSessionTicket messages to vend.  This extension is only applicable

>       such services to vend tickets to clients to use for accelerated

>    A supporting server MAY vend TicketRequestContents.count

>    tickets they are willing to vend to clients.  Thus, the number of

typos: send, sended

I think that the use cases should list a situation in which the client does 
not expect to perform session resume, so it can inform the server of that by 
sending the value 0.

The draft does not state what is the expected behaviour with tickets in 
relation to post-handshake authentication.

The draft does not state if the extension is negotiated once per session or 
its values should be reused for resumed sessions.

The draft does not state how the extension interacts with Hello Retry Request 
handshake. Can it be dropped/added/changed in 2nd CH message? What is expected 
to happen when client does change it?

>    Servers that support ticket requests MUST NOT echo "ticket_request"
>    in the EncryptedExtensions.

It's not spelled out what the client is expected to do when server does 
violate this expectation. I'd say it should abort with unsupported_extension.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 08 Jun 2019 06:33:31 -0700

Thanks for the comments, Hubert! Please see inline below.

> > tickets they are willing to vend to clients. Thus, the number of

Good catch -- will fix.

> not expect to perform session resume, so it can inform the server of that by 

Good suggestion! We can certainly add this. 

> relation to post-handshake authentication.

As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document.

> its values should be reused for resumed sessions.

It's intended to be once per session, and we'll add that.

> to happen when client does change it?

Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too.

> violate this expectation. I'd say it should abort with unsupported_extension.

That seems reasonable to me.

Thanks again for the comments. We'll incorporate them into a next revision ASAP.

Best,
Chris (no hat)