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

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

On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > 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.
> 
> sounds good
> 
> > > > > 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.
> 
> huh? I see the following in the draft-02:
> 
>    Servers MUST NOT
>    send more than 255 tickets to clients.

I was referring to the "SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the MUST NOT above should also be a SHOULD NOT. Thanks for your patience in working through the kinks!

> 
> 
> -- 
> 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
> Attachments:
> * signature.asc