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

[Hubert Kario <[e-mail]>]

On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <[e-mail]> wrote:
> > 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
> 
> I think we agree on the problem which is it is hard to have a specific
> count as tickets may be sent at multiple time during the key exchange or
> the later during the session. If the "SHOULD" is addressing this aspect I
> believe that more text is needed.. From my perspective, what I proposed  I
> imagined that count was related to the maximum number of ticket provided
> **each time the server is sending tickets**. The reason for having the same
> number is that the server does not know how the client will use these
> tickets and the client does not know precisely when the server sends the
> tickets. So at the end the number of tickets sent is likely to be n*count
> when n represents the number of times during the session tickets are
> provided.
> 
> My understanding of the SHOULD is that it makes legitimate for a server to
> ignore the count value provided by the client.

yes, it looks like we are in agreement

Sounds like something that should be spelled out explicitly in the draft. I.e. 
it should talk about groups of tickets, not tickets in connection, and it 
should definitely not specify the maximum number of tickets a server can send 
in a connection.
 
> > > 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_______________________________________________
> > 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