Hi Cynthia, On Fri, Jul 24, 2026, 19:39 Cynthia Revström <[email protected]> wrote:
> Hi Tobi, > > I don't really agree with your argument. > Just because I don't think there is a good reason to do it, doesn't > mean that we should get rid of it. > I can't think of a good reason to have 10 levels of subdomains, yet we > allow that. > > It also feels weird to bring this up again as it was brought up in > SC-86 and it seemed like the decision ended up being to block > in-addr.arpa and ip6.arpa but not e164.arpa. > Having this discussion again so soon when (as far as I know) very > little has changed regarding the circumstances doesn't feel like a > sensible use of time. > Well, you asked, I think. It's not like I intend to focus all my energy on this, but that's what I think. Speculation regarding what the IETF might have plans for in the future > also doesn't really feel like proper justification. > > As I said in my previous email, if I recall correctly the reason to > block in-addr.arpa and ip6.arpa was to allow them to be used for CAA > records for IP addresses. > That is a very concrete and valid use-case and likely the best > solution to the problem of CAA for IP addresses. > Nothing like that exists for e164.arpa so any comparisons to > in-addr.arpa/ip6.arpa seem inappropriate to me. > > I still haven't heard any real objective argument that isn't very > vague speculation. > > Also I actually just thought of one reason, not a great one, but one > nonetheless. > If you want to be able to host a SIP server on your phone number, > being able to get a publicly trusted TLS servers cert would be useful. > That is a use case that you can't otherwise accomplish unlike with the > rDNS domains (as there you could simply host a server on the IP > address itself). > You are actually making my point for me. You are basically saying that a non-web use case you can think of can rely on WebPKI. My perspective differs. Cooptation of WebPKI has burned us before and already existing cooptation will again and probably does right now, though I can't think of a good example, so maybe not, but as sure as sunrise it will again. The core issue is that other consumers and RPs outside of web browser usage don't generally seem to be able to keep up with the speed required to keep our users safe when it comes to keeping up with changes in the BRs etc., and when a blocking use case can't just be left hanging out to dry (say pos terminals, or, uh, appmatus), it suddenly requires us to compromise between the security of our uses and not setting the world aflame. I can respect that you don't share that perspective or consider it relevant, but within it I'd think the argument is valid. Tobi -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAHHcmY8poO61wAHDPMbAjH-%2BXZaHVfpDh_s9bqwMbauacv-HOw%40mail.gmail.com.
