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

[Daniel Migault <[e-mail]>]

Hi,

Please see my comments.

Yours,
Daniel
On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood <[e-mail]> wrote:

> Hi Daniel,
>
> Please see inline below.
>
> On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> > 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'd prefer we didn't merge them, though admittedly I don't feel strongly
> about this one way or the other.
>
> > 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.
>
> Indeed. I think this is fairly clear from the draft. How would you suggest
> this be clarified?
>
The draft does not seem, in my opinion, to address the case when values are
hard coded. OK hardcoded is just there to expose it cannot chose the value.
It is fine.

>
> > 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.
>
> The document states this:
>
>    A supporting server MAY vend TicketRequestContents.count
>    NewSessionTicket messages to a requesting client, and SHOULD NOT send
>    more than TicketRequestContents.count NewSessionTicket messages to a
>    requesting client.
>
> Is this not sufficient clear? If not, how can it be improved?
>
> > I would rather see the count value as a hard line from the server with
> > a MUST NOT instead of a SHOULD NOT statement.
>
> As this is merely a hint from the client, I don't think this is necessary.
>
> I believe we could be more specific than a hint, and a server supporting
the extension MUST NOT send more tickets then specified. This is what is
expected when count is set to 0.


> > 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.
>
> This behavior is orthogonal to the intent of the hint. Imagine, for
> example, clients sent no hint and servers decided to do what you describe
> above. The same issues would still exist (tracking some count sent on the
> server, deciding which tickets to use on the client, etc.). Thus, I don't
> think this would add much value.
>
> If the servers receives a count value and sends tickets right after the
Finished message and after the post handshake authentication. How many
messages do you expect to be sent at each round?  I suggested to have count
at each round, as the server does not know how the client expects to use
these tickets. I have the impression the current text says count.

> >
> > 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.
>
> The text lists this:
>
>    Servers SHOULD place a limit on the number of tickets they are willing
> to vend to clients.
>
> The draft mentions limitation of tickets to avoid computation of the
server, and I was reading the limit as to limit that computation, in which
case the limit addresses server's resource exhaustion. What I meant was the
use of the extension with a spoofed IP address.


> Though we can add a parenthetical to indicate that failure to do so may
> result in doing more work that intended.
>
> Thanks for the feedback!
>
> Best,
> Chris
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>