>> I'm quite uncomfortable with the bit that says you look up the policy >> at https://policy._mta_sts.example.com/current > >That's surely a mistake. It should have been a ".well-known" >URI at the domain with no prefixes.
We talked about this at great length over dinner in Buenos Aires. Demanding a web server at the same domain name used in e-mail addresses is operationally a non-starter for large organizations. >> _sts._tcp SRV 0 0 443 sts-policy.example.com. > No, SRV records break the security model, because untrusted DNS now > supplies the reference identifier. The URI needs to be entirely > determined from the nexthop domain with no insecure inputs. In the absence of DNSSEC, there's *always* insecure inputs, such as the A or AAAA records that point to the web server. As the next two sentences said: Bad guys could spoof your SRV record without DNSSEC, but they can also spoof the A record for policy._mta_sts.example.com so that horse left the barn. You could require that the target of the SRV has to be a subdomain of the original domain which, along with the signed SSL certificate, would limit the scope of evil. >> The string "sts0" is deliberately invalid punycode, so while xn--sts0 >> is a valid hostname label, it's not an A-label and will never appear >> in an IDN hostname, Hence it's very unlikely to collide with other >> uses. I hope I don't have to explain why it's a kludge. My CA will >> sign it. I checked. > >This is not a good idea, such names will be rejected by some systems. Got any examples? I haven't looked very hard either way. Note that nothing should be trying to turn it into a U-label. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
