>We'd like others to review and encourage further discussion relating to these >drafts. Thank you for your time.
I'm quite uncomfortable with the bit that says you look up the policy at https://policy._mta_sts.example.com/current By my reading of RFC 3986 which defines URIs, that's not a URI. Section 3.2.2. does have ABNF which allows underscores in the host part, but it then has text on page 21 that says that names looked up in the DNS are RFC 1123 hostnames that are letter, digit, hyphen only. It says the underscores are intended for names looked up in other ways. My CA (Startcom) won't sign names with underscores, and I doubt that other CAs will, which makes them rather unappealing. I have two suggestions, a reasonable one and a gross kludge. The reasonable one is to use SRV, so it'd be like this: _sts._tcp SRV 0 0 443 sts-policy.example.com. 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. This proposal has the advantage of being built on top of well established standards, and the disadvantage that looking up SRV records is still alleged to be hard in some contexts (but I don't think ones that matter here.) The gross kludge is to use xn--sts0 as the tag, e.g. https://policy.xn--sts0.example.com/current 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. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
