Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Tommy Pauly <[e-mail]>]

> On Jan 31, 2020, at 6:14 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> I have no particular position about this draft but
> am curious about 2 things:
> 
> #1 I don't get why it's not possible for postfix to
> determine the best way to manage tickets based on the
> destination port to which the ClientHello is sent. I
> totally get why that won't solve 100% of cases, but it
> would surely solve a huge percentage? Apologies if an
> answer was already posted as part of this v. long
> thread.
> 
> #2 I don't get why Viktor's request for special handling
> for value 255 is a real problem for anyone. We have
> another thread today envisaging 2040 extensions flags,
> so I really have a hard time seeing what here justifies
> rejecting Viktor's argument. FWIW, this thread has not
> provided me with an obvious answer to #2 other than "not-
> invented-here." I'm not sure that declaring things in the
> rough where the only identifiable issue is NIH is the
> overall best outcome, longer term.

That’s a fair point, and worth clarifying. Totally agree that NIH isn’t a good reason. Instead, it seems unclear what value the special use of 0 and 255 adds that wouldn’t be better served by a separate extension.

Today, without any sentinel values, 0 means the client hints that it doesn’t need any tickets, and N means that the client hints that it would like N tickets. Whether or not a ticket is intended to be reused is not part of this, and ticket reuse is elsewhere discouraged.

As far as I understand the proposal, the meaning currently expressed by sending 0 would be expressed by sending 255 instead; and sending 0 would take on a new meaning that is “send a ticket if you want, and I may try to reuse a ticket if you don’t send one”, which seems like the behavior already expressed by not sending the ticket request message at all (since not passing the message is equivalent to no hint).

To that end, the proposed change doesn’t seem to add any new signaling capabilities, but makes the meanings of numbers less intuitive.

If the hint is intended to be “I’m planning on reusing tickets, let me know ahead of time if I shouldn’t”, that seems like it could be an explicit signal sent that doesn’t need to reuse a field that is a numeric count of tickets being requested. It seems like there is a small number of clients that would use this, so adding another message to signal this and potentially more info about reuse policy would make more sense and could be fleshed out in more detail separately. For example, if we add the proposed hint that presumably means “if you give me a new ticket, I’ll use it; but if you don’t, I’ll reuse an old one”, the client is essentially forcing a server that doesn’t want ticket reuse to issue a new ticket; whereas a more explicit signal could indicate that the server won’t allow ticket reuse, so the client shouldn’t even try, etc, without necessarily giving out new tickets. 

Best,
Tommy

> 
> Cheers,
> S.
> 
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls