On Friday, 15 November 2019 13:00:14 CET, Daniel Migault wrote:
Hi Hubert,
On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario <hka...@redhat.com> wrote:
On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:
Hi Hubert,
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
yes. I would consider the NST as part of the handshake even for those sent
after the post-handshake authentication.
that would make tickets useless for sessions that use PHA
I agree better terms may be used.
The rekey aspect seems to me out of the handshake.
rekey also don't impact the keys used for derivation of session ticket
secrets...
so how exactly you want to decide when server stopped sending NSTs after
handshake finished?
That the spec does not mention it does not mean this will not be defined.
Instead it means each implementer will have its own logic, definitions and
outputs. The same reasoning occurs to the complexity argument,not
specifying it does not reduce the complexity but let it to the
implementation with all unexpected corner cases.
my point is that there is no good way to define it, if you want the count
to be
limited, you need provide a good way to do that
I say that there isn't one, so defining it is futile
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?
Again, it would be a bug but the current spec is very permissive, at least
in my opinion. I do not believe that not specifying the expected behaviors
will prevent misbehaviors to happen, it, instead simply legitimates them.
a MUST requires strict definition, which we can't provide, a SHOULD is
already
in the draft
--
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
