On Wed, Mar 06, 2013 at 02:08:48PM +0100, Ond?ej Sur? wrote:
> If you want to be compatible with DANE, I would suggest to
> implement the protocol as is, pretty please.
The implementation will be fully *interoperable* with DANE as
specified. The Postfix SMTP client will however be more liberal
than the spec in its interpretation of certificate usages 0 and 1.
Specifically:
- 0 will be read as 2 with a "CA constraint" interpreted as a
"trust anchor assertion".
- 1 will be read as 3 with a "service certificate constraint"
interpreted as a "domain issued certificate".
- No trust-chain validation will be performed above the trust
anchor in the conflated 0/2, or at all in the conflated 1/3.
- MTA administrators will be strongly encouraged to publish
"TLSA 3 1 1" RRs in preference to any other kind. This
eliminates most opportunities for failure with no reduction
in security. I would like to see this best-practice advice in
draft-ietf-dane-smtp, and any final resulting RFC.
The working group will I hope understand that in some application
areas considerations beyond the literal text of the DANE RFC may
dictate similar choices, and that as a practical matter it is
important to not erect needlessly high adoption barriers when the
cost of absolute RFC adherence is high, and the benefit is low or
absent.
The above decisions will be clearly documented, together with a
detailed rationale. They will not cause any interoperability
issues, and will eliminate many opportunities for mail delivery
between sites failing for avoidable reasons, including:
- Some over-worked and under-trained sysadmin assumes that his
issuing public CA is on everyone's list of trusted public CAs.
Browser users can click-through the warnings, but sending MTAs
are not interactive applications and mail delivery will fail.
- Some over-worked and under-trained sysadmin configures a trust
chain that includes only the leaf certificate without intermediates.
They specify "TLSA 1 x y" in DANE, but mail delivery fails because
the sending MTA can't do the PKIX check.
- Some over-worked and under-trained (Azure cloud?) sysadmin forgets
to renew a certificate that is published as "TLSA 1 x y" in DANE.
...
Of course some similar and related problems will remain, most
notably failure to re-sign a DNSSEC zone in a timely manner and
dropping off the Internet for all DNSSEC-aware recursive resolvers.
Stil, on the whole DANE adoption will go much more smoothly without
avoidable service disruption barriers.
As you've all tired of hearing by now, in the case of MTA to MTA
traffic, given indirection through DNS MX records, the security of
DNSSEC is an unavoidable foundation with no opportunity for CAs to
provide an additional *independent* validity assertion. The best
that CAs can do is provide revocation support, but the code and
operational cost of implementing this in an MTA is prohibitive.
So PKIX public root CAs do not add any value beyond serving as
potential trust anchors in a "TLSA 2 x y" or "TLSA 0 x y" RR.
A non sado-masochist MTA developer will not subject his users to
frequent avoidable outages and himself to a flood of "the MTA is
broken" help requests just to adhere to the letter of an RFC when
adhering only to its essential elements will not expose users to
any new risk.
Widespread DANE adoption would be a giant leap forward in email
security, let's hope DANE is a sufficient carrot to encourage users
to endure the pain of deploying DNSSEC.
> (On the other hand, the existing MTA implementations don't give
> a damn about existing standards, so it will be status quo anyway.)
[ Note to self: don't feed the trolls. ]
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
