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

[Viktor Dukhovni <[e-mail]>]

On Sat, Feb 01, 2020 at 02:13:37AM +0000, Stephen Farrell wrote:

> #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.

The Postfix SMTP server does not actually create the listener socket,
and may not even be getting the traffic directly from the network
(e.g. haproxy, postscreen, DNAT, ...).

Such a heuristic would require action from the server administrator to
configure appropriate policy for each non-default instance of an SMTP
service, and would then still yield only approximately correct results.
SMTP relays aren't always on port 25, and services that are dedicated
MSAs are sometimes in fact on port 25.

Also, though I wish other MTAs that support TLS resumption would also
reuse tickets, avoiding waste.  I don't know what TLS stacks they use,
and whether they need or don't need fresh tickets.  And coversely not
every server Postfix connects to is also Postfix, and those may have a
different default behaviour.

So I'm looking for a mechanism (absolutely trivial per #2 below) to
allow the client to signal to the server its ticket-use preference
so that the server can vend the right number of tickets (which is
the scope of this extension).

> #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.

I am also puzzled by the reticence to make the trivial change that makes
the mechanism more expressive at negligible cost, and move on.  That too
advances the draft.  I want to see this draft move forward, that's why
I am bothering to try and make it cover the missing piece of the puzzle.

There is NO obligation on either party to enable reuse even if the
client sends the "as necessary" sentinel (0).  The server can just vend
1 new ticket in that case, and the client would need to assume the
previous one invalid and use the new one for the next connection.

The proposal does not change the security posture of any systems that
don't want to support reuse.  Also the draft as written does not prevent
consenting peers from doing reuse, it just fails to provide them with a
simple mechanism to negotiate a mutually compatible policy.

When the two ends make differt assumptions you get either waste or
insufficient tickets to meet the client's needs.

Let's make a small change to the code points to enable more precise
negotiation and move on...

-- 
    Viktor.