On Thursday, 14 November 2019 17:19:55 CET, 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.
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.
we discussed it on the list, and the reason for such phrasing is
multi-fold:
- the server doesn't have to implement this extension, as such, as per the
basic TLS 1.3 RFC, it can send arbitrary number of extensions to client,
so clients, to be RFC compliant, need to be able to process abritrary
number
tickets at arbitrary time after handshake finish
- making value in extension the exact number requested by client makes the
implementation much more complex: is that number per connection? per
session? what about post-handshake authentication? what about Session
Ticket
Encryption Key rollover? do we really want the client to abort the
connection
if server misbehaves and sends too many or too few tickets?
- while the client may think that it knows how many tickets it requires,
that
information may be out of date. If an HTTP server has been brought down,
a
connection to a given SNI may lead to a redirection page - in such cases
there is no point in server sending tickets.
so please, tell: what issue would be solved by making the count requested
by
client mandatory?
Because I see it only increasing complexity of implementation for no
benefit.
--
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
