Phil Pennock <pdp@???> wrote:
>
> draft-ietf-dane-srv §7.1 explicitly does not change MX ordering in the
> presence of mix-security SRV/MX lists.
>
> It seems that when presented with a secure list of original
> MX->hostname(+port) mappings, it's reasonable to assert that the demands
> of maintaining path security mean that a client MAY choose, when
> presented with a set of hostname->address mappings, to prioritise those
> which maintain security; this prevents downgrade attacks where knocking
> out one link's DNSSEC status (subverting DNS controls) allows the
> attacker to bypass all TLSA checks.
But even if you do change the sorting rules as you suggest, an attacker
can still use various DoS techniques to force the client to fall back to
the insecure server. Mixing secure and insecure servers has to work in
order to support incremental deployment, but it is supposed to be a
transitional state. I don't see any point in working hard to support a
setup that cannot be properly secure and that isn't supposed to exist for
any length of time. So the specification says don't change the sorting
logic because it is unnecessary complexity and a waste of effort.
Our response (as MTA authors) to a site with incomplete TLSA deployment
should be, finish deploying it if you want proper security. That is where
the effort should be applied.
I should perhaps make the reasoning in the security considerations section
clearer.
> I'm inclined to provide a mode which says "if some of the entries are
> DNSSEC validated, but not all, then this is equivalent to no network
> connectivity to the unsigned entries and they should be skipped, just as
> if there were no route to the host".
This is likely to have unhappy consequences if a site's third party backup
MX gains TLSA records but its primary does not.
> So, for Exim, and using Jeremy's "security=dane" suggestion (in
> preference to "dane") as a starting-point, I'm seeing these three
> options for a Router:
Why do you think "dane" needs to be an option? Can't it be supported by
default? I'm trying to write the specs so that it should just work from
the point of view of the user/admin of client software.
I don't think making it a generic security= option fits the style of the
existing TLS / AUTH options, which are fairly specific. So if you have to
have a dane option it should look like dane=flag/flag/flag.
> Next: my current strategy for implementation in Exim, as outlined in a
> separate mail, only supports selector=0 (full certificate). Do we see a
> lot of selector=1 SubjectPublicKeyInfo deployment in the wild?
> Similarly, matching-type=0 (exact match). This is a consequence of my
> "grab the cert to a temporary file" strategy, and my bias towards using
> PKIX-less modes for SMTP MX. We can certainly add the rest later, but
> do you see significant harm with initial support only being for X00 TLSA
> modes?
That is probably OK for an early prototype, but full TLSA support will be
necessary.
Following the discussion with Viktor Dukhovni (a Posifix developer) I have
thought a bit more about non-PKIX deployment. It seems to me that TLSA
records should ideally grow new selectors to support PGP keys /
fingerprints (as in RFC 6091 / monkeysphere) and raw keys
(draft-wouters-tls-oob-pubkey). Something to keep in mind for the longer
term.
> If we suddenly are requiring CA conformance for any host which does not
> have an independent trust-anchor, then this creates bad social pressures
> on postmasters, to trust CA Foo just because BigImportantRecipient uses
> CA Foo for their certs, even though CA Foo may have some "unfortunate"
> practices.
Agreed, to some extent. This isn't too bad if the context is limited to
just SMTP+DANE since the DNS restricts which CAs are trusted to
authenticate a particular server. You are perhaps right to worry about the
second-order effects, though they are dwarfed by the effects of which CAs
browsers choose to trust.
> Thus my current thinking: DNSSEC and "security = dane" turns on
> "tls_try_verify_hosts = *". In the presence of a usage=(2,3) TLSA
> record, this is elevated to "tls_verify_hosts = *" and we will
> hard-reject certificate validation failures. In the presence of a
> usage=(0,1) TLSA record, we attempt to validate the trust path to the
> certificate in the record. If that fails, we proceed anyway, treating
> it like a validation failure, but then for the TLS connection
> certificate validation, we still treat a mis-match as a hard-reject
> failure.
I think this is a bad idea. It sounds like it would introduce tricky error
cases that could lead to spoofing, especially for usage=0. If the server
wants usage=2 then they should say so.
Tony.
--
f.anthony.n.finch <dot@???>
http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
