Hi Hubert,
I do not understand why tickets sent after PHA would be useless. It is also
unclear if not one solution means there are multiple good solutions - in
which case we could pick one - or that there is not one. At least I would
envisioned something around the lines below.
For a given handshake as presented below, here are the NST with associated
number (n_0, ..., n_3) without any count value provided by the client. When
the client provides count I would expect these number to become (n'_0, ...,
n'_3) with n'_u = min(max(count- sum(n'_j, j<u), 0), n_u). Basically, you
send n_0, n_3 until counter is reached. Other NST are ignored. This seems
to ensure that only count NST are sent while not being overly complex. I
believe that have a deterministic behavior from the server is beneficial.
Of course this is a first draft, and this may be refined.
Client Server
ClientHello
+ key_share -------->
ServerHello
{Finished}
<-------- [Application Data*]
<-------- NST (n_3)
{Certificate*}
{Finished} -------->
<-------- NST (n_2)
[Application Data] <-------> [Application Data]
<--------- NST (n_1)
<-------- CertificateRequest
PHA response --------->
<--------- NST (n_0)
Yours,
Daniel
On Fri, Nov 15, 2019 at 8:44 AM Hubert Kario <[email protected]> wrote:
> 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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
