5 ms·

What about <somedomain>.co.uk ? Or the various other TLD that are 2-level deep already ? I believe it's impossible to implement this properly.

nitrogen 11y ago
There's a huge suffix list that browsers use to control things like cookie scope: https://en.wikipedia.org/wiki/Public_Suffix_List https://en.wikipedia.org/wiki/Public_Suffix_List https://publicsuffix.org/ https://publicsuffix.org/ Probably includes https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
pdkl95 11y ago
While I think it is a bad idea to limit which domains can use TLS in an ad hoc style, this issue with stuff like example.co.uk was solved in DNS a long time ago. One of the main features of DNS is the ability to delegate authority for a zone. You use a NS record on a valid name that where you have authority to indicate that some other server is authoritative for a given subset of your zone. If you bought example.com, you can create DNS records like subdomin.example.com. 172800 IN NS ns1.example.com to indicate that ns1.example.com is the authority for the entire subdomain.example.com zone. This includes all further nesting of .subdomain.example.com. Instead of guessing* who is responsible for a zone, you should simply ask the nearest upstream zone authority. Also, relying on lists is almost always the wrong solution - if your security requires you to successfully enumerate something, you are doing it wrong. ( http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d... )
- pfg 11y ago
  What you're saying is true, but in the context of CAs, it's still important to be able to distinguish real public suffixes from regular authority delegations for subdomains. CAs need to be able to filter and block CSRs for wildcard names like *.co.uk or something similar. This also applies to things like cookie scopes in browsers. Currently, the Public Suffix List is your best bet here. The Dbound WG[1] is working towards a standardized solution that doesn't require enumeration in a centralized list but rather works through DNS records. This should eventually replace the PSL, although I suspect most use cases will still rely on some kind of preload list (similar to HSTS) in addition to that. [1]: https://tools.ietf.org/wg/dbound/ https://tools.ietf.org/wg/dbound/
  - Animats 11y ago
    There's an authority delegation problem where "example.com" wants to delegate "adblaster.example.com" to some ad service. The owner of "example.com" needs to approve this, but the party named in the certificate is not "example.com", but the AdBlaster service. On the other hand, since this feature is used almost solely for advertising, there's no reason Let's Encrypt should offer this service for free. Let the ad guys buy those certs from Verisign and verify them with both parties manually.

nitrogen 11y ago

There's a huge suffix list that browsers use to control things like cookie scope: https://en.wikipedia.org/wiki/Public_Suffix_List https://en.wikipedia.org/wiki/Public_Suffix_List https://publicsuffix.org/ https://publicsuffix.org/ Probably includes https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...

pdkl95 11y ago

While I think it is a bad idea to limit which domains can use TLS in an ad hoc style, this issue with stuff like example.co.uk was solved in DNS a long time ago. One of the main features of DNS is the ability to delegate authority for a zone. You use a NS record on a valid name that where you have authority to indicate that some other server is authoritative for a given subset of your zone. If you bought example.com, you can create DNS records like subdomin.example.com. 172800 IN NS ns1.example.com to indicate that ns1.example.com is the authority for the entire subdomain.example.com zone. This includes all further nesting of .subdomain.example.com. Instead of guessing* who is responsible for a zone, you should simply ask the nearest upstream zone authority. Also, relying on lists is almost always the wrong solution - if your security requires you to successfully enumerate something, you are doing it wrong. ( http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d... )

pfg 11y ago
What you're saying is true, but in the context of CAs, it's still important to be able to distinguish real public suffixes from regular authority delegations for subdomains. CAs need to be able to filter and block CSRs for wildcard names like *.co.uk or something similar. This also applies to things like cookie scopes in browsers. Currently, the Public Suffix List is your best bet here. The Dbound WG[1] is working towards a standardized solution that doesn't require enumeration in a centralized list but rather works through DNS records. This should eventually replace the PSL, although I suspect most use cases will still rely on some kind of preload list (similar to HSTS) in addition to that. [1]: https://tools.ietf.org/wg/dbound/ https://tools.ietf.org/wg/dbound/
- Animats 11y ago
  There's an authority delegation problem where "example.com" wants to delegate "adblaster.example.com" to some ad service. The owner of "example.com" needs to approve this, but the party named in the certificate is not "example.com", but the AdBlaster service. On the other hand, since this feature is used almost solely for advertising, there's no reason Let's Encrypt should offer this service for free. Let the ad guys buy those certs from Verisign and verify them with both parties manually.