Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Hubert Kario <[e-mail]>]

On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> I understand the meaning of count is the higher limit of ticket and the
> server can provides any tickets between 0 and count. If that is correct,
> this could be clearly stated and indication to chose an appropriated value
> for each cases may be provided.
> 
> I would rather see the count value as a hard line from the server with a
> MUST NOT instead of a SHOULD NOT statement.

see my previous comments: this ignores existence of post handshake 
authentication, ticket lifetimes and KeyUpdate
 
> The ability to request 255 tickets with one byte can be seen as an
> amplification vector, especially when a server sends directly the tickets
> after its Finished message. I believe that additional text in the security
> consideration could be added.

true
 
> Yours,
> Daniel
> 
> On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <[e-mail]> wrote:
> > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > > > > ```
> > > > > > > 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?
> > > > 
> > > > Sorry, I meant connection:
> > > >    "Clients may indicate to servers their desired number of tickets
> > 
> > for *a
> > 
> > > > single connection* via the following "ticket_request" extension"
> > > > 
> > > > This is a simple hint for servers. Nothing more. No state needs to be
> > 
> > stored
> > 
> > > > past connection establishment.
> > > 
> > > sounds good
> > > 
> > > > > > > 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.
> > > > 
> > > > Since these hints are not mandatory to honor I don't think we need to
> > > > describe this case. In particular, this is a valid case where ignoring
> > 
> > the
> > 
> > > > SHOULD is fine, in my opinion.
> > > > 
> > > > If the draft required that servers MUST NOT send more tickets than
> > 
> > what's
> > 
> > > > requested, then yes, I think these details would be important.
> > > 
> > > huh? I see the following in the draft-02:
> > >    Servers MUST NOT
> > >    send more than 255 tickets to clients.
> > 
> > I was referring to the "SHOULD NOT send more than
> > TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the
> > MUST NOT above should also be a SHOULD NOT. Thanks for your patience in
> > working through the kinks!
> > 
> > > --
> > > 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
> > > Attachments:
> > > * signature.asc
> > 
> > _______________________________________________
> > 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