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

[Daniel Migault <[e-mail]>]

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,
> >
> > 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
>

I agree the case of count set to 0 is mention. However, the support of the
extension does not prevent a server to send 4 tickets with MAY and SHOULD.
The reason this might be ignored in the future is that the specification
does not prevent the server from doing so and takes what the client
provides as an hint which may be overwrite by the server. 0 seems also
special, but I believe we can have a common behaviour for any sort of
values.


> as for memory – just because server sends them, doesn't mean client has to
> remember them
>
It still has to process them, which consumes battery.

>
> finally: ok, so the server misbehaves and sends 4 tickest instead of
> three,
> what the client should do? close the connection?
>
> Well, the client will probably discard one. That said with the current
specification we cannot report a bug and ask the server to comply with the
spec, it is in the spec. On the other hand, if the spec ask for considering
that count, we can ask the server to be compliant with the spec. All cases
you are raising will need to be implemented and as such will be defined in
some ways. In my opinion that should be in the specification.


> > 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. I agree better terms may be used.
The rekey aspect seems to me out of the handshake.


> 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.

>
> > 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.

>
> > Yours,
> > Daniel
> >
> > On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario <[e-mail]> 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
> >> [e-mail]
> >> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>