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 <c...@heapingbits.net>
> 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
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
