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

["Christopher Wood" <[e-mail]>]

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

On Fri, Jun 7, 2019, at 4:37 AM, Hubert Kario wrote:
> On Friday, 7 June 2019 01:47:25 CEST [e-mail] wrote:
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-01
> 
> > clients without server-side, per-client state. Servers vend an
> 
> > 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

Good catch -- will fix.

> 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.

Good suggestion! We can certainly add this. 

> The draft does not state what is the expected behaviour with tickets in 
> 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.

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

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

> 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?

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.

> > 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.

That seems reasonable to me.

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

Best,
Chris (no hat)