On Tue, Apr 24, 2018 at 10:21:28AM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk <ka...@mit.edu> wrote:
> > 
> > To be clear, the current draft explicitly says "Servers SHOULD issue
> > new tickets with every connection."  This is not a MUST, but is
> > perhaps strong enough guidance to merit overriding the existing
> > ticket callback semantics.
> 
> Fine advice for browsers, but not terribly useful for Postfix.
> Multiple processes read and write the session cache in parallel,
> and single-use tickets won't work without serialization and
> multiple cache slots for the same destination.
> 
> The Postfix SMTP server needs to be able to issue tickets only
> as-needed on the server.  The TLS 1.2 model works just fine for
> SMTP and STEKs are already properly rotated.

I'm not trying to say that Postfix or even SMTP in general needs to
adopt the TLS 1.3 (Web) model; I'm only trying to consider the
OpenSSL 1.1.1 library default, which I think ought to honor the
SHOULD in the spec.

> I think that the previous behaviour of the callback needs to
> continue to apply, if the callback does not return re-issue,
> no new ticket should be returned.  The callback has access
> to the SSL handle and can determine the protocol version
> if it so chooses.

and will not automatically update to TLS 1.3 semantics by default.
But maybe that's okay.

> The built-in ticket callback can always re-issue if that's
> the preferred default.

I think that is the preferred default, and would not object to
implementing the default in the built-in ticket callback if you
insist on Postfix not having to change its callback to get its
preferred behavior.

-Ben
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to