On Tue, Sep 06, 2016 at 10:25:55PM +0200, Daniel Margolis wrote:
> I may be missing something, but surely anything an attacker can do to a SRV
> record they can do to a CNAME or A record for a host itself.
Generally, with SRV records, one would expect that the reference
identifier for certificate name checks is the target hostname, not
the service domain.
Note also that the nexthop domain itself (example.com vs.
mta-sts.example.com or similar) typically operates multiple https
services, many of which would deny (404) the existence of the STS
policy resource, and thus clear the policy cache.
> So hardcoding the hostname itself doesn't do much against attackers who
> can arbitrarily inject DNS records. (The defense here is really in the
> SSL cert validation and the assumption that nobody is serving untrusted
> content on .well-known/...)
It is not that simple. The target URI has be verifiably the right
URI for STS policy lookup, not just some random web service associated
with the domain.
Furthermore, STS is subject downgrade attacks via MITM redirection
to unintended HTTPS servers that have a wildcard cert for the
domain, and so the STS spec may need to specifically forbid wildcard
certificate matching.
A bad alternative is to not support authenticated policy revocation
via a 404 response, treating that as a transient lookup error, but
this is not a good outcome. You might need to extend the spec to
support serving an explicit policy revocation response.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
