On Monday, 30 September 2019 15:36:36 CEST Christopher Wood wrote: > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote: > > On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote: > > > This version addresses some of the comments we received from Hubert a > > > while > > > back. We think it's ready to go for WGLC, modulo whatever nits folks > > > find. > > > > > > :-) > > > > I still see the "vend" instead of "send" typos... Same for "vended" > > It's not a typo! We chose to use vend.
then you're not consistent:
As per [RFC5077], and as described in [RFC8446], TLS servers send
:)
> > ```
> >
> > Clients must therefore
> > bound the number of parallel connections they initiate by the
> > number of tickets in their possession, or risk ticket re-use.
> >
> > ```
> >
> > I'm not a native speaker, but shouldn't it be "...therefore bind the
> > number..."?
>
> Yes, we can fix it in the next version.
>
> > ```
> > Servers MUST NOT send more than 255 tickets to clients.
> > ```
> >
> > per what? session? at a time? connection?
>
> This is all per session. We can state it explicitly in the next version.
so this count needs to be kept as part of session and impacts connections that
perform resumption?
> > what's the expected behaviour with tickets and post-handshake
> > authentication? Are tickets sent after PHA also bound by this limit?
>
> As mentioned earlier, there is no effect, so we left it out. We're happy to
> accept text should you think it's needed.
If the I-D states that servers should not send more tickets than the client
asked for, and then send exactly that amount, then they won't be able to send
new tickets after PHA and remain compliant.
Yes, it's completely up to the server to decide if to send tickets after PHA
or not, and I'm not suggesting that the client should request for tickets in
one of its PHA messages, much less expect or require them, but sending tickets
after PHA is reasonable and explicitly stated behaviour:
RFC 8446 Section 4.6.1:
For instance, the server might send a new
ticket after post-handshake authentication in order to encapsulate
the additional client authentication state.
so the I-D should explicitly state what's the expected behaviour in that case.
IMHO, the extension should be used for the tickets sent right after the
handshake, it should not put an upper bound for the tickets that a server can
send in a single connection. For a very long lived connection (especially if
the connection uses KeyUpdate messages regularly), the initial tickets may
expire. Server may notice that and send a new group of tickets then.
> > ```
> >
> > Clients MUST NOT change the value of TicketRequestContents.count in
> > second ClientHello messages sent in response to a HelloRetryRequest.
> >
> > ```
> >
> > 'A server MUST abort the connection with an "illegal_parameter" if the
> > value of the extension changed, it was added or removed in second
> > ClientHello.' ?
> I don't think this is necessary.
given past discussions on this mailing list, I don't think this is entirely
obvious....
Then what about the addition or removal of extension being forbidden? Can we
add something like this?:
```
The presence or absence of the extension MUST be maintained in second
ClientHello message when compared to first ClientHello in connection.
```
--
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
