1129618 - please add .onion to public suffix list

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: Domain Lists, defect)

Description

[Daniel Kahn Gillmor]

Attachment: add-.onion.diff

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Iceweasel/35.0.1
Build ID: 20150130021009

Steps to reproduce:

tor's .onion addresses (like facebookcorewwwi.onion) belong to the service operators who control the corresponding secret key material.

.onion identifiers are also being certified by Digicert (see for example the subjectAltName extension in facebook.com's certificate)

.onion should be added to effective_tlds.dat to reflect this situation.

Comment 1

[Ryan Sleevi]

.onion is already implicitly handled through its omission (thus falling to the * rule, causing foo.onion and bar.onion to both be separable cookie domains)

However, .onion lacks a formal registration, so it would seem unwise/squatty to add to the TLD list until IANA has taken action to ensure it's a special-purpose domain.

Comment 2

[Daniel Kahn Gillmor]

The lack of .onion in the PSL is causing chromium to show a degraded lock icon for https connections, even though they're fully validated:

  https://bugs.debian.org/777083

As for squattiness -- i don't know that we need to wait for ICANN.  .onion has effectively been "squatted" for years now.  It's well established, and i know of no objection for the use of the TLD to designate Tor hidden services.

If IANA is working on acknowledging this reality, is there somewhere that we need to give them a nudge too?

Comment 3

[Ryan Sleevi]

(In reply to Daniel Kahn Gillmor from comment #2)
> The lack of .onion in the PSL is causing chromium to show a degraded lock
> icon for https connections, even though they're fully validated:

This is a Chrome issue, but no, they're not fully validated. If someone submitted a patch to the PSL and it was approved (it's not clear it would be, per https://publicsuffix.org/submit/ ), I would remove it when integrating into Chrome.

Without getting into too much detail, .onion names are not validated properly (any CA can issue for any entity claiming to own them). There is a ballot to resolve this in the CA/Browser Forum (of which Google is endorsing) - see https://cabforum.org/pipermail/public/2015-February/004922.html - but even if that ballot passes, it doesn't make .onion appropriate for the PSL.

If the Facebook bug were filed in the Chromium tracker, I'd close it as WontFix (Working as Intended)

> As for squattiness -- i don't know that we need to wait for ICANN.  .onion
> has effectively been "squatted" for years now.  It's well established, and i
> know of no objection for the use of the TLD to designate Tor hidden services.
> 
> If IANA is working on acknowledging this reality, is there somewhere that we
> need to give them a nudge too?

Sorry, the Internet works best when people work together. In the case of DNS, it works because there is a hierarchy and authority. Indeed, the PSL exists to reflect that authority (and at greater levels than just the IANA root zone database). The argument here is a bit specious - there is far more domain squatting on .home, .intranet, .corp, etc - but that doesn't make them intrinsically appropriate for the PSL, nor would someone be able to submit an amendment that foo.corp be added to the PSL (as there is no registry for .corp).

There is a draft to reserve these domains in the IANA registry, which would make them appropriate for addition. That draft is https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names . You should poke the DNSOP list ( https://www.ietf.org/mailman/listinfo/dnsop ) where you can see the draft is still in active discussion.

Fairly sure this should be Resolved/WontFix, but I leave it to Gerv to clarify the PSL's policy for non-IANA assigned names

Comment 4

[Jothan Frakes]

Historically, to keep the PSL volunteers on the primary focus of providing service to the community and clear of passionate conflicts surrounding namespaces, there was a decision made to follow ICANN's ICP-3.

This keeps things fairly cut and dry.

Comment 5

[Gervase Markham [:gerv]]

(In reply to Ryan Sleevi from comment #1)
> .onion is already implicitly handled through its omission (thus falling to
> the * rule, causing foo.onion and bar.onion to both be separable cookie
> domains)

Very true.
 
> However, .onion lacks a formal registration, so it would seem unwise/squatty
> to add to the TLD list until IANA has taken action to ensure it's a
> special-purpose domain.

I agree. Although I wouldn't have put it in these terms when we started the PSL, ICP-3 is the right attitude:
https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-en

If we were to add .onion, what would we say when alt root operators come along and ask for their TLDs to be added? We need internet governance consensus; Ryan is right when he points you to that I-D.

> The lack of .onion in the PSL is causing chromium to show a degraded lock icon for https connections, > even though they're fully validated:

The actions taken by each user of the PSL with information in the PSL is a matter for them (although we provide guidance about what we intend the PSL to mean). As Ryan has made it clear that adding .onion to the PSL will not change the behaviour of Chrome/ium in this matter, there is no point in doing so for that reason.

Other entries on the special-use domain list:
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
are not in the PSL, but I'm happy to say that we would consider names listed there on a case-by-case basis.

Gerv

Comment 6

[Daniel Kahn Gillmor]

(In reply to Ryan Sleevi from comment #3)

> This is a Chrome issue, but no, they're not fully validated. If someone
> submitted a patch to the PSL 

(fwiw, this bug report is a patch submitted to the PSL, as best i could figure out; if there is some more appropriate way to submit a report to the PSL, i hope someone will update the PSL documentation)

> Without getting into too much detail, .onion names are not validated
> properly (any CA can issue for any entity claiming to own them). There is a
> ballot to resolve this in the CA/Browser Forum (of which Google is
> endorsing) - see
> https://cabforum.org/pipermail/public/2015-February/004922.html - but even
> if that ballot passes, it doesn't make .onion appropriate for the PSL.
>
> If the Facebook bug were filed in the Chromium tracker, I'd close it as
> WontFix (Working as Intended)

To clarify: i think you're saying if the CABForum ballot passes, then (after the appropriate time elapses for all revocations to be issued) Chromium will stop degrading the security indicator for https .onion connections, without .onion being added to the PSL.  Is that correct?

> There is a draft to reserve these domains in the IANA registry, which would
> make them appropriate for addition. That draft is
> https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names . You
> should poke the DNSOP list ( https://www.ietf.org/mailman/listinfo/dnsop )
> where you can see the draft is still in active discussion.

Thanks for the pointer.