Viktor Dukhovni <viktor1dane@???> (Do 08 Mai 2014 17:35:38 CEST):
> On Thu, May 08, 2014 at 05:24:30PM +0200, Heiko Schlittermann wrote:
>
> > I fully agree.
> > I'm thinking of something about that way (not sure, if I
> > got the ${acl{}} feature right?
> >
> > begin acl
> >
> > acl_check_dane:
> > accept verify = dane
> > deny
> >
> >
> > begin transports
> >
> > remote_smtps:
> > driver = smtp
> > hosts_require_tls = *
> > tls_continue = ${acl{acl_check_dane}}
> >
> > This give the user the power to implement whatever he wants
> > as the condition.
… I was just loudly thinking, with no claim to have the final solution
already :)
> There is nothing here that tells the engine to do DANE in the first
> place, or that assumed to already be in place?
> The SMTP "driver" would have to have performed DNSSEC validated MX
> lookups, sent the MX hostname in SNI, and made sure to disable
> anonymous cipher-suites, before this check is invoked. Is there
> separate configuration to "condition" the connection for later
> DANE checks?
Good point. I was just approaching from the configuration side, not from
the implementation.
As soon as the driver starts it will know about the tls_condition, but
I'm not sure, if the driver will be able to know that the ACL *will*
check for DANE.
But … OTOH, if we always use DNSSEC (and fallback to DNS, remembering
the answer is untrusted now), we have everything we need for the DANE
checks, as soon as we see the certificate, haven't we?
> The check looks too easy to omit. What's wrong with simpler driver
> configuration parameters rather than a "tls_continue" hook?
remote_smtps:
driver = smtp
hosts_require_tls = *
tls_require_dane = yes # defaults to yes
# but for using DNSSEC it's too late
# already, because it's done in the
# routers
But … before wasting our time here, I'll have to check what Todd did
already for/with DNSSEC.
> Perhaps configuration through code fragments is simply the Exim
> way?
Yes, I understand Exim as a MTA framework :) With a minimalistic set of
assumptions about the problems to be solved and about the way how the
problems should be solved. Probably the perlish TIMTOWTDI is shining
through.
> Is that always better? Sometimes Turing-complete mechanisms
> get out of hand. They are nice to have, but perhaps should only
> be a fallback when more direct mechanisms are insufficient.
Agreed. With the exception, that for Exim I would not say 'nice to have',
I'd say 'must have', but nothing prevents us from providing nice and
comfortable shortcuts. (The smtp driver knows about 80 options
(generic + specific), but usually does not need any of them, since they
have sensible defaults.)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-
