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

[Daniel Migault <[e-mail]>]

Hi,

Please find some comments on the draft.

In the introduction, I believe both limitations may be merged into one
limitation which is the number of ticket is a server only decision. The
purpose of the extension is the client providing information so the server
can pick the appropriated number.

I find "choose" and "hard-coded" a bit contradicting. If the server uses a
hard coded value for the number of tickets, then I would understand the
limitation as the server being unable to chose a value per client or per
connection. This seems to me an implementation limitation and so maybe out
of scope of the extension. If it is able to choose that number, the
limitation is that it is a server only decision.

I understand the meaning of count is the higher limit of ticket and the
server can provides any tickets between 0 and count. If that is correct,
this could be clearly stated and indication to chose an appropriated value
for each cases may be provided.

I would rather see the count value as a hard line from the server with a
MUST NOT instead of a SHOULD NOT statement.

My reading of 8446 is that NewSessionTicket messages can be sent at
multiple time during or after the handshake. If that is correct, it seems
to me quite complex to track the number of tickets that had been sent.
Typically, if I have to send them at different time how much would I send
at each flight. I would rather consider the min(count, server_limit) as the
number of tickets in any batch of NewSessionTicket messages. We may also
ask the client to only keep the latest batch of tickets and delete the
others previously sent tickets.

The ability to request 255 tickets with one byte can be seen as an
amplification vector, especially when a server sends directly the tickets
after its Finished message. I believe that additional text in the security
consideration could be added.

Yours,
Daniel



On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <[e-mail]> wrote:

>
>
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>