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

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

On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > ```
> > > Servers MUST NOT send more than 255 tickets to clients.
> > > ```
> > > 
> > > per what? session? at a time? connection?
> > 
> > This is all per session. We can state it explicitly in the next version.
> 
> so this count needs to be kept as part of session and impacts connections that 
> perform resumption?

Sorry, I meant connection:

   "Clients may indicate to servers their desired number of tickets for *a single connection* via the following "ticket_request" extension"

This is a simple hint for servers. Nothing more. No state needs to be stored past connection establishment.

> > > what's the expected behaviour with tickets and post-handshake
> > > authentication? 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.
> 
> If the I-D states that servers should not send more tickets than the client 
> asked for, and then send exactly that amount, then they won't be able to send 
> new tickets after PHA and remain compliant.
> 
> Yes, it's completely up to the server to decide if to send tickets after PHA 
> or not, and I'm not suggesting that the client should request for tickets in 
> one of its PHA messages, much less expect or require them, but sending tickets 
> after PHA is reasonable and explicitly stated behaviour:
> 
> RFC 8446 Section 4.6.1:
>    For instance, the server might send a new
>    ticket after post-handshake authentication in order to encapsulate
>    the additional client authentication state.
> 
> so the I-D should explicitly state what's the expected behaviour in that case.
>
> IMHO, the extension should be used for the tickets sent right after the 
> handshake, it should not put an upper bound for the tickets that a server can 
> send in a single connection. For a very long lived connection (especially if 
> the connection uses KeyUpdate messages regularly), the initial tickets may 
> expire. Server may notice that and send a new group of tickets then.

Since these hints are not mandatory to honor I don't think we need to describe this case. In particular, this is a valid case where ignoring the SHOULD is fine, in my opinion.

If the draft required that servers MUST NOT send more tickets than what's requested, then yes, I think these details would be important.

> 
> > > ```
> > > 
> > >    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.' ?
> > I don't think this is necessary.
> 
> given past discussions on this mailing list, I don't think this is entirely 
> obvious....
> 
> Then what about the addition or removal of extension being forbidden? Can we 
> add something like this?:
> 
> ```
>      The presence or absence of the extension MUST be maintained in second 
>      ClientHello message when compared to first ClientHello in connection.
> ```

That works for me. We can add it in the next version. 

Best,
Chris