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

From: [email-masked]
Date: Fri, 27 Sep 2019 16:47:16 -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-02.txt
	Pages           : 6
	Date            : 2019-09-27

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

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

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: "Christopher Wood" <[email-masked]>
Date: Fri, 27 Sep 2019 16:59:42 -0700

This version addresses some of the comments we received from Hubert a while back. We think it's ready to go for WGLC, modulo whatever nits folks find. :-)

Best,
Chris (no hat)

On Fri, Sep 27, 2019, at 4:47 PM, [email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hubert Kario <[email-masked]>
Date: Mon, 30 Sep 2019 15:28:05 +0200

On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> This version addresses some of the comments we received from Hubert a while
> back. We think it's ready to go for WGLC, modulo whatever nits folks find.
> :-)

I still see the "vend" instead of "send" typos... Same for "vended"

```
      Clients must therefore
      bound the number of parallel connections they initiate by the
      number of tickets in their possession, or risk ticket re-use.
```

I'm not a native speaker, but shouldn't it be "...therefore bind the 
number..."?

```
Servers MUST NOT send more than 255 tickets to clients.
```

per what? session? at a time? connection?

what's the expected behaviour with tickets and post-handshake authentication?
Are tickets sent after PHA also bound by this limit?

```
   Clients MUST NOT change the value of TicketRequestContents.count in
   second ClientHello messages sent in response to a HelloRetryRequest.
```

'A server MUST abort the connection with an "illegal_parameter" if the value 
of the extension changed, it was added or removed in second ClientHello.' ?

-- 
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: Mon, 30 Sep 2019 06:36:36 -0700

> I still see the "vend" instead of "send" typos... Same for "vended"

It's not a typo! We chose to use vend.

> I'm not a native speaker, but shouldn't it be "...therefore bind the 

Yes, we can fix it in the next version.

> per what? session? at a time? connection?

This is all per session. We can state it explicitly in the next version.

> Are tickets sent after PHA also bound by this limit?

As mentioned earlier, there is no effect, so we left it out. We're happy to accept text should you think it's needed.

> of the extension changed, it was added or removed in second ClientHello.' ?

I don't think this is necessary.

Best,
Chris

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 30 Sep 2019 14:56:19 +0100

> Yes, we can fix it in the next version.

"Bound" reads correctly to me.  You could spell it out in detail
if it is thought confusing:

  "Clients must therefore not start a number of parallel connections
  larger than the number of tickets in their possession"

-- 
Cheers,
  Jeremy