It feels like allowing wildcards will help with adoption, because web domains [that use them] can then reuse their existing certificates for STARTTLS. Deployment and cert reuse are essential to making progress; creating key-management challenges for small companies will mean that traffic continues in the clear.
I agree that 404 should be a soft fail for the reasons you listed, Dan. /m -- Mark E. Risher | [email protected] | 650-253-3123 On Wed, Sep 7, 2016 at 2:46 AM, Daniel Margolis <[email protected]> wrote: > If we forbid wildcards, the argument against the two level hostname goes > away. That is, the only argument against "policy.mta-sts" is that it breaks > "example.com" wildcards! I think there's a reasonable argument for going > that direction, as you say, though, hence my question for input here. Do we > prefer to make deployment and cert reuse easy at slight risk of attacks as > described? > > Regarding 404s (a slight tangent now), I am not sure we do want to treat > that as revocation. To me, a 404 runs a somewhat higher risk of operational > mix-ups, and revocation can be had more explicitly but serving a policy > with a very short max-age (which we could make explicit, i.e. "max-age of > zero equals revocation"). > > On Sep 6, 2016 22:45, "Viktor Dukhovni" <[email protected]> wrote: > >> 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 >> > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
