On Wed, Apr 13, 2016 at 10:34:20AM +0100, Neil Cook wrote:
> > Yes, but if you have a self-signed cert, you aren't going to have an
> > STS policy, so that's a different scenario than what we're discussing, no?
[ Response to up-thread comment ]
If a domain publishes both DANE and STS policy indeed both need to
be correct. Which to use when both are published is perhaps just
local policy, but some guidance may be appropriate.
In particular because opportunistic authentication (please read
RFC7435, and then sections 1.3 and 3.1 of RFC7672) can be viewed
a policy of receiving system that the sending system is playing
along with, fragile policies are best avoided, lest senders throw
in the towel and disable SMTP transport security, because it is
more trouble than it is worth.
Now of DANE and STS have their separate pain points:
* DANE: Cert rotation can be tricky, users may need to
update DNS before replacing their certs. Some will botch
this from time to time.
However, with "3 X X" TLSA records certificate expiration and
hostname matching are not relevant, so authentication works
even with "expired" certs or certs that don't match the MX
hostname, or for chains that lack otherwise required intermediate
CA certs.
* STS: Users will forget to renew certificates, and name checks
need to work, and the CA needs to be trusted by the sender.
Missing intermediate certs (often not added when renewing
certs) are also a frequent problem.
Certificate transparency may also enter the picture at some
point, and provide more ways for WebPKI authentication to
fail (missing SCTs in stapled OCSP, unsupported log servers,
...).
If we require *both* to work, there are just too many ways to lose.
The sender typically is willing to send in the clear, and is doing
TLS because *some* traffic deserves better and to thwart pervasive
monitoring.
Setting the bar too high is often counterproductive.
So my view is that for SMTP DANE is by far the more natural of the
two transport security mechanisms, and that STS is essentially a
medium-term work-around for the complexity of cost-justifying DNSSEC
in the face of internal organizational politics at the large
providers.
In that light, the more natural mechanism is used when available,
and the work-around is a secondary strategy.
> Well, both need to work independently as you say below. But I might still
> have an STS policy (using a different, CA-signed cert) where I have a
> self-signed cert for DANE, because I want to support clients who only
> support one or the other. Forcing clients to validate both doesn�t seem
> to be a good idea.
This can't work. An MTA will present the same certificate chain
to STS and DANE clients alike.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
