On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:
Hi Hubert,
The reason I would prefer the client to enforce the count is that if a
client has constraints - memory / bandwidth, he wants to make sure its
preference is respected, and this independently of the evolution of how the
hint will be interpreted in the future or depending on different
implementations.
bandwidth I sort of understand, but then if client asks for 0 tickets, it's
explicitly stated in the draft that server should understand it as "will
not use, don't bother" – I really don't see how in the future that can be
reinterpreted as "nah, send tickets anyway" – also, please remember that
the size of the ticket is very variable, so just accepting one ticket may
be a significant size anyway
as for memory – just because server sends them, doesn't mean client has to
remember them
finally: ok, so the server misbehaves and sends 4 tickest instead of three,
what the client should do? close the connection?
I understand the reasons for SHOULD. At least this should be documented. To
address your first point, of course the specification applies to the server
that support the extension.
Your second concern is solved by limiting the
NTS of KEX.
by "KEX" you mean handshake? but New Session Ticket messages are not sent
during handshake, they are sent after handshake is finished
so how exactly you want to decide when server stopped sending NSTs after
handshake finished?
The third point is addressed by the minimum of the (count,
server_nbr). Note that I see count as a maximum. Overall I do not think
this would add much complexity. The only complexity I see is when a server
sends NTS at different time in the KEX.
again, and what if the server misbehaves?
Yours,
Daniel
On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario <hka...@redhat.com> wrote:
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 ...
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
--
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
