Tony, [note public CC]
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.
Indeed, when presented with a wish to switch to secure-by-default
MTA->MTA delivery, having a TLSA anchor available for any of the MX's
hostnames means that _only_ such hostnames can be verified by default.
MX doesn't guarantee that the client _must_ use the lowest MX available;
RFC 5321 section 5.1 says:
----------------------------8< cut here >8------------------------------
MX records contain a preference indication that MUST be used in
sorting if more than one such record appears (see below). Lower
numbers are more preferred than higher ones.
----------------------------8< cut here >8------------------------------
So the preference indication MUST be used in the sorting, but it does
not say that this has to be be _only_ factor in the sorting, merely that
it has to be taken into account, used in the sorting. The next
paragraph is confusing, but is talking about sorting of multiple address
records for one host, not relative ordering of hosts.
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".
I can see that I'll also have to supply a mode which doesn't change the
MX ordering, but I am coming to the conclusion that using this mode is a
slavish obedience to a pre-secure RFC, when being more flexible will
markedly improve security while remaining compatible with the 5321
specifcation, since we have a _list_ of suitable MXes, and any of them
should be suitable for use.
In real world operational terms, I know that some folks do things like
set up alternate MXes which evaluate any traffic to them as "primary MX
bypass" and spam-sign (and they get bitten when the primary fails, or
there's a route flap somewhere). Even for these situations, this
"prefer secure MX entries" approach is entirely compatible: it's the
same people that would be deploying such an MX-semantic-differential
strategy that would also be deploying DNSSEC, or at least within their
organisation, so they're in a position to make sure that they don't make
their spam-trap MXes the only secure ones.
I'm not seeing any real world damage from MX-prefer-secure.
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:
security = dane/prefertlsa
security = dane/prefersecure
security = dane/prefermxfirst
security = dane/preservemxorder
So: if we have a client choosing how to order the results of an MX
lookup and adding security into the mix (else, why bother with DNSSEC AD
examination at all) then:
* /prefertlsa -- prefer TLSA-present records, then DNSSEC-AD records,
then the Insecure; within each of the three bands, sort by MX
* /prefersecure -- just prefer DNSSEC-AD and then Insecure; within
each of the two bands, sort by MX
* /prefermxfirst -- aka Insecurity Prevails, first use MX ordering
but within an MX level, prefer TLSA/Secure to Insecure
* /preservemxorder -- aka Insecurity Prevails, only use MX ordering
I'm inclined to then make "security = dane" default to /prefertlsa.
This is the only option which allows for actually defaulting to working
trust anchor information.
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?
Part of the reason for this is that with both OpenSSL and GnuTLS to
support, I want to restrict this to a common subset of functionality,
and providing complete certificates as trust anchors is something that
both fundamentally support, whereas probing into the structure is going
to require rather more API abstraction work. With this X00 approach, we
get to support X={0,1} by checking trust paths from system/other certs
to the TLSA record, before establishing the connection, and then use the
retrieved cert as the trust anchor, just as for the X={2,3} cases.
In this case, given N TLSA certs for a given hostname, if any one of the
N is X00, we're good, and if none are, we treat them as "unusable". Per
RFC 6698 §4.1, if it's unusable, it doesn't matter for verification
purposes, so our lack of handling does not trigger connection abort.
This doesn't affect rollover, unless someone's rolling over from X00 to
not-X00.
I'm going to be adding a new dane.c file to handle the routines relating
to matching, so as we want to delve deeper into the X.509v3 structure,
to handle the other non-zero selector/matching-type values, we have one
place to handle the logic.
Thoughts?
-Phil
