On Fri, Nov 17, 2023 at 09:57:42AM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <ietf-d...@dukhovni.org> writes:
>
> >Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against
> >OpenSSL 3.2 (release estimated circa next week), will automatically signal
> >client certificate types X.509(0) and RPK(2) iff and only a client
> >certificate is configured (available).
>
> Could this use/behaviour be referenced somewhere to provide guidance for
> implementers in general? It'd be good to have this made an official way to do
> things rather than just being done on an ad hoc basis.
What did you have in mind? I guess an updated "mTLS flag" draft that
recommends overloading the cert type extension to signal the client's
willingness to provide any one of the advertised cert types on request.
> >AFAIK, today just two MTAs are doing SMTP with raw public keys, both are
> >mine.
>
> You have to wonder about the qualifications for being a standards-track RFC
> if, after ten years, the total installed base (at least for MTAs) is one
> person.
Well, not surprising, since the supporting code in both Postfix and
OpenSSL is brand new, and not yet present in any official release of
either OpenSSL or Postfix,
I'm running a pre-release Postfix snapshot compiled against a
pre-release version of OpenSSL, because I am the author of the RPK
support code for the former, and played a major role in guiding and
reviewing the underlying TLS code in the latter.
So it isn't the case that operators shied away from using RPKs, rather
they've had no opportunity to deploy it. Some time next year, users
running the latest/greatest releases will also start signalling and,
at times actually using RPKs. Large-scale adoption will of course take
a few years, because for that, the new code has to be bundled with some
operating system that users upgrade to.
The same of course would apply to hypothetical software supporting any
new "mTLS flag" extension, so it plausibly looks like the existing cert
type extension may be fit for purpose. Unless we discover a popular TLS
stack that sends the cert type extension by default, even in the absence
of a client cert it is willing to send, or worse, also then aborts the
handshake if a cert is subsequently requested.
--
Viktor.
P.S. Gory details re RFC7250 RPK specifically:
Enabling use of cert type RPK(2) involves 4 separate signals:
1. Client's CTOS (client to server) cert types, listing the cert
types the client is willing to send. This is what we're
discussing to potentially overload as an "mTLS flag".
It should be able to function as a client-to-server mTLS signal,
even when neither end has any interest in RPKs as such.
2. Client's STOC (server to client) cert types, this lists the types
of server certificates the client is willing to accept.
3. Server's CTOS (client to server) cert types, this indicates the
certificate types the server is willing to accept from the client.
4. Server's STOC (just application's TLS stack configuration, never
sent on the wire as an extension) cert types, listing the types
server certificates the server is potentially willing to send to
client. The server just sends the preferred mutually supported
cert type, no need for a prior signal.
In Postfix RPKs are enabled in 1 and 4 by default, either end is always
willing to *send* RPKs when supported by the other.
For "2", the client is always willing to accept RPKs, when
authenticating a server with exclusively DANE-EE(3) TLSA records. It
will optionally, subject to a non-default boolean configuration:
http://www.postfix.org/postconf.5.html#smtp_tls_enable_rpk
also accept RPKs from the server when doing unauthenticated
opportunistic TLS (a lerge fraction of SMTP message tranmission falls
into this bucket), mandatory unauthenticated encryption or the
"fingerprint" security level, when all fingerprints are public key
fingerprints, which the operator "promises" by setting the parameter
to "yes".
For "4", the server is only willing to accept client RPKs when
http://www.postfix.org/postconf.5.html#smtpd_tls_enable_rpk
the operator indicates that all certificate-based access controls
(or other uses of the requested client cert) need only the public key,
and not the full certificate:
http://www.postfix.org/postconf.5.html#smtpd_tls_enable_rpk
this setting is also off by default.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
