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

From: [email-masked]
Date: Fri, 18 Jan 2019 16:32:35 -0800

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-00.txt
	Pages           : 6
	Date            : 2019-01-18

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 specify the desired number
   of tickets needed for future connections.

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-00
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-00

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: Mon, 21 Jan 2019 16:09:57 +0100

On Saturday, 19 January 2019 01:32:35 CET [email-masked] wrote:
> 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.
> 

> https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-00

The security section probably should note that large server self-imposed limit 
could be used for Denial of Service.

"Servers MUST NOT send more than 255 tickets to clients."
across the whole connection or directly after Finished? For long-lived 
connections that may be problematic, especially when connected with multiple 
post handshake authentication exchanges...

What about ticket count after post handshake authentication? Should we allow 
the client to re-issue the extension in Certificate message?

Should handling of "0" in extension be special? As in, if client is asking for 
0 tickets (e.g. because it will not do resumption), "SHOULD" the server 
respect that and send no tickets? (while the min(srv_limit, 
clnt_request.count) will do that, I think it may be prudent to spell it out)

Is the extension negotiated every time when resuming the session, or should it 
be saved as part of session data by server? What if client starts advertising 
it, drops it or changes value in the next ClientHello that offers resumption?

I'm assuming that it cannot be changed by client in 2nd ClientHello when doing 
Hello Retry Request handshake. Shouldn't that be stated explicitly though?
-- 
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