> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni <[email protected]> wrote:
>
> On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote:
>
>>> - 0x01-0xfe => client wants single-use tickets:
>>> + send up to that many tickets on full handshake,
>>> + however, generally send just 1 ticket on resumption, or when
>>> replacing tickets during long-lived connections. This helps to
>>> reduce chronic ticket "oversupply".
>>
>> Having a recommendation to generally just send one ticket
>
> You left out the key qualification: "on resumption". Now perhaps
> that strategy is only needed in the *absence* of any signal from
> the client, and with the extension the onus is perhaps on the client
> to send "1" once it has enough tickets, in which case the server
> does not need to apply the heuristic that helps it to avoid chronic
> ticket oversupply. In which case, the "generally send just 1" can
> be left out, it is a side comment, not essential to the overall
> proposal.
That would be great to leave that out.
>
> Somebody should try to avoid ending up with N new tickets after
> every connection, but in could well be the client.
Yes, I think that can and ought to be the client. The client is really the only
party that can know how many tickets have been "consumed" by potentially failed
attempts to connect that the server didn't see in time or got dropped.
Thanks,
Tommy
>
>> doesn't address the motivating use case for the document, which is Happy
>> Eyeballs (connection racing). Having multiple tickets is required in a steady
>> state, so we shouldn't recommend against that.
>>
>> Any client that wants to only do the reuse case can just not use this
>> extension.
>
> No, the extension is *very* useful to such clients, to signal to the server
> that that's what they want to do, so that the server then only issues new
> tickets when necessary.
>
> --
> Viktor.
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls