Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Daniel Migault <[e-mail]>]

Hi,

If tickets are sent right after the server Finished, before the the client
Finished, these are only triggered by the clientHello - at least this is my
understanding.

Yours,
Daniel


On Thu, Nov 14, 2019 at 11:25 AM Christopher Wood <[e-mail]>
wrote:

>
>
> On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote:
> > Hi Chris,
> >
> > Thanks for the responses, please see my comments inline.
> >
> > Yours,
> > Daniel
> >
> > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <[e-mail]>
> wrote:
> > > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> > >  > Hi,
> > >  >
> > >  > The current version is clearer than the previous one. However, as I
> > >  > understand the document, it still seems very asymmetric in the sense
> > >  > that it does not provide the client the ability to enforce a
> number. I
> > >  > believe more guidances/specifications are needed on how to
> interpret the
> > >  > count value. Interpretation is usually based on implicit
> assumptions of
> > >  > today's usages, and explicit signaling should, in my opinion, be
> preferred. In
> > >  > other words, I believe that long term interop will benefit from
> these
> > >  > additional specifications.
> > >
> > >  I disagree with this assessment. The document is clear on this:
> > >
> > >  A supporting server MAY use TicketRequestContents.count when
> > >  determining how many NewSessionTicket messages to send to a
> > >  requesting client, and SHOULD place a limit on the number of tickets
> > >  sent. The number of NewSessionTicket messages sent SHOULD be the
> > >  minimum of the server's self-imposed limit and
> > >  TicketRequestContents.count.
> > >
> > >  As has been stated before, the count is a *hint* to the server,
> nothing more.
> > >
> > That is my point, in my opinion a hint is under specified.
>
> I acknowledge your opinion, but as I think I've made clear, I don't agree.
> Sorry!
>
> > >  > The problem stated in the introduction is that the server needs some
> > >  > information from the client in order to generate the appropriated
> number
> > >  > of tickets. In fact the client is likely to be the one that better
> knows
> > >  > the number of tickets to be generated, but the current text does not
> > >  > enable the client to enforce that number. Instead this is entirely
> left
> > >  > to the server.
> > >
> > >  As above, I think you're misunderstanding the point of this document.
> Ticket requests are hints to servers.
> > >
> > On the contrary, I think I understood it correctly.
> > >  > Typically, if a device does not want to have more than one ticket.
> It
> > >  > should be able to indicate one and be sure it will only receive one
> > >  > ticket. The current specification does not prevent multiple tickets
> to
> > >  > be sent by the server.
> > >
> > >  Right, nor should it. Again, that's not a goal.
> > >
> > >  > The server can ignore the count value (MAY) even
> > >  > though it is known to support the extension. This means that a
> server
> > >  > could support the extension while still having a hard coded number
> of
> > >  > tickets. In addition, (SHOULD) let the server determining the
> number of
> > >  > tickets.
> > >  >
> > >  > Possible ways to address my concerns could be to limit the count
> value
> > >  > to the number of tickets generated during the KEX, and a server
> MUST NOT
> > >  > exceed the counter value. The text would need more guidance on how
> the
> > >  > server SHOULD behave when emitting at different time in the KEX -
> after
> > >  > the Finished message and after the post handshake authentication.
> > >
> > >  I don't think any text changes are needed to address these comments.
> > >
> > >  > The security consideration should in my opinion consider the fact
> that a
> > >  > client over UDP/DTLS may use the count value as an amplification
> factor
> > >  > to have the server flooding a target. The current text only seems to
> > >  > consider the computation aspect, not the bandwidth. If that cannot
> > >  > happen, it might be beneficial to add it. However, when a server
> sends
> > >  > tickets right after the Finished, it seems to me that can be used
> as an
> > >  > attack.
> > >
> > >  I'm not convinced this is useful to add. The target here is the
> client (attacker) that requested tickets.
> > The target is the spoofed source IP address.
>
> That would imply the attacker is able to complete a connection with this
> spoofed address, no?
>
> > >  Best,
> > >  Chris
> > >
> > >  _______________________________________________
> > >  TLS mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>