On Fri, Aug 21, 2020 at 10:59:11AM -0400, Wietse Venema wrote:
> > Viktor Dukhovni:
> > > - &&TLS_DANE_BASED(state->client_start_props->tls_level))
> > > + && TLS_DANE_HASTA(state->client_start_props->dane))
> > > msg_warn("%s: DANE requested, but not available",
> > > state->client_start_props->namaddr);
>
> Should there be a warning when tls_dane_avail() fails AND the
> TLS_DANE_BASED is true?
Not needed if TLS_DANE_HASTA is not true, because:
- For a DANE-based policy without DANE-TA TLSA RRs to have
made it to tlsproxy(8), all the DNS preconditions have
already been satisfied, and DANE-EE TLSA records have
been provided to tlsproxy(8).
- In Postfix 2.11–3.5, DANE-EE checks are performed post-handshake.
Specifically, in particular the DANE-style X.509 verification
callback is not needed and is not enabled (is set back to
WebPKI default) on the shared SSL_CTX.
> Would the following be more correct:
>
> int missing_infrastructure = 0;
> if (!tls_dane_avail()) { /* mandatory side effects!! */
> /* True DANE request. */
> if (TLS_DANE_BASED(state->client_start_props->tls_level)) {
> msg_warn("%s: DANE requested, but not available",
> state->client_start_props->namaddr);
> missing_infrastructure = 1;
> }
> /* Not DANE, but TA support implicitly dependss on the DANE stack. */
> else if (TLS_DANE_HASTA(state->client_start_props->dane)) {
> msg_warn("%s: TA support requested, but DANE is not available",
> state->client_start_props->namaddr);
> missing_infrastructure = 1;
> }
> )
> if (missing_infrastructure == 0)
> state->tls_context = tls_client_start(state->client_start_props);
No, because DANE-EE works without tls_dane_avail. We just check the
certificate fingerprint post-handshake.
> But wait, there is more...
>
> > > state->appl_state = tlsp_client_init(state->tls_params,
> > > state->client_init_props,
> > > - TLS_DANE_BASED(state->client_start_props->tls_level));
> > > + TLS_DANE_HASTA(state->client_start_props->dane));
>
> Will this also use the right verify callback function pointer when
> real DANE is requested? Or does real DANE not use those same
> callbacks?
In Postfix 2.11–3.5, the real DANE-EE does not use the custom
DANE-specific X.509 verification callbacks, they're only needed
for DANE-TA verification.
The dichotomy was between WebPKI-style chain verification and DANE-TA
(or "tafile") chain verification. When all the TLSA records are
DANE-EE, no chain verification is performed, we just do a post-handshake
fingerprint check (supporting both DANE-EE and the "fingerprint"
security level).
All this simplified in Postfix 3.6. Speaking of which, upgrades from
3.5 to 3.6 need to perform a "reload", to flush the TLS session cache.
Otherwise, some cached sessions returned by the "old" tlsmgr(8) to
new smtp(8) may have the wrong properties. One way to avoid this is
to include "mail_version" in the session lookup key hash. We should
probably do that...
--
VIktor.
