> > > 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.
>
> If that would lead to unhappy consequences, why are they advertising
> that host as being acceptable to handle deliveries for them?
Well I don't think third party backup MXs are wise, but they are supposed
to work, and this spec isn't the place for that argument :-) My aim is to
allow incremental deployment without surprising gotchas. For example, say
I have a third party MX, and they have deployed DNSSEC and DANE, but this
doesn't affect me since my DNS is unsigned. When I decide to tackle DNSSEC
I am likely at first to be unaware of the subtleties of DANE, so it would
be an unpleasant surprise if signing my zone pushed my incoming mail to my
backup MX.
I'm not especially happy with the security considerations subsection about
the trust relationship between a service domain and its target servers.
But I think this discussion has given me an idea for a few more helpful
words.
> Usage=0 or usage=1 in TLSA making their way into a store-and-forward
> system leads to backpressure blackmail and a losing game for everyone
> except those trying to extract rent from the security ecosystem.
Yes. I think for inter-domain SMTP the PKIX usages are worthless, since
the existing stuff that is out there does not validate certificates, so
the backwards compatibility concerns are very different. For protocols
with clients that currently validate, there is perhaps some tiny value in
continuing to support CA cert revocation (even if it is amazingly crappy).
But probably the only value is for the CAs themselves...
My aim is to make this stuff protocol-independent not just as a bit of
architectural wank, but so that it can be turned into reusable code. Even
if Exim and Postfix don't take up that opportunity :-) Hence simplicity
and uniformity, and not dicking around with the base DANE logic, even if
that means there are unnecessary checks with some combinations of options.
It probably is the right thing to treat 0/1 the same as 2/3. But that's an
argument about RFC 6698 which belongs on the DANE list not in my spec :-)
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.
