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

[Hubert Kario <[e-mail]>]

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 <[e-mail]> 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