I suppose it's too late to delete Punycode from the world, but I would like to understand exactly what security aspects are affected both by adding support to the library and by not adding it.

The security aspect I'm most aware of is homograph attacks: https://en.wikipedia.org/wiki/IDN_homograph_attack

Those are why presumably why browsers render http://кто.рф/eng/ as http://xn--j1ail.xn--p1ai/eng/ in the URL bar.

But should this work?

     c, err := net.Dial("кто.рф:80")

Or:

    res, err := http.Get("http://кто.рф/")

I can type http://кто.рф/ into my URL bar and it loads. Requiring all users working with such URLs to do this seems onerous:

    u, err := url.Parse("http://кто.рф/")
    if err != nil { 
        ... 
    }
    u.Host, err = idna.ToASCII(u.Host)
    if err != nil { 
        ... 
    }
    res, err := http.Get(u.String())

The other security aspect is substring searching.

But it's already the case that strings.Contains(req.URL.Host, "рф") in an http.Handler won't work, as browsers already send Punycode.

I think for security the best thing to do is be consistent which fields contain which form at all times, and document it.

For what little it's worth, I did look into the topic of Unicode host names when working on url.Parse earlier in the cycle. Go 1.4 and earlier preserved them as is. Go 1.5 %-encoded the non-ASCII bytes (clearly not right). Go 1.6 goes back to the earlier preservation. For URL parsing the general rule is that the fields of the URL struct are unencoded, so it seemed best to keep Host in its original form, especially in non-web uses of URLs (like when people use mysql://whatever).

I looked at what seemed to be relevant RFCs at the time and it looked like the HTTP protocol needed one algorithm for mangling to ASCII while DNS needed a different one. Maybe I misunderstood, but that split seemed another argument in favor of keeping the URL.Host field unmangled, and for keeping URL.String() unmangled at least for now.

I agree that we should figure out how to make http.Get etc do the right thing. Internally http.Get already calls url.Parse, so if there is http-specific url mangling to do, it can be done there.

Similarly we should figure out how to make net.Dial do the right thing, whatever that is.

I've experienced needing to handle this at Bitly, so i'll add my 2cents.

I think url.Parse should not handle IDN/Punycode conversion, as an IDN formatted Host is a valid URL format, and a URL struct constructed with an IDN Host (without using Parse) should also work. Changing round trip semantics of url.Parse(u).String() also seems like a backwards incompatible change of the type that's hard to detect. The Host just needs to be ascii safe when used in a HTTP Host header, which implies to me net/http responsibility. That means, as suggested, calling idna.ToASCII() before sending the Host header or TLS SNI where appropriate.

Also, as a side note, the same IDN/Punycode issue also applies to the construction of the Referer host header in refererForURL as that should also be ascii safe for use in a header.

When handling requests on the server side, I think the Host header should be left as-is (presumably in punycode if from a well behaved browser/client, but we all know that isn't always the case), but ToUnicode would also be reasonable.

It's unclear to me what, if any, restriction net.Dial should have on unicode or IDN domains as DNS as i believe punycode is a DNS convention not a requirement (i need to do some RFC reading to be better informed on this one).

Didn't happen for 1.7.

The parser and encoder of net/mail.Address doesn't handle Punycode either. I've found it as a surprise(perhaps should be documented) because Address.Name is word-encoded/decoded.
The latest email RFC obsoletes both Punycode and word-encoding so I would say that the trend is to support native UTF-8. How it's displayed to the end user may be a different story.

Edit: net/mail doesn't need additional documentation. After more research I've found that
"IDNA does not update the existing email standards, which allow only ASCII characters in local parts". Therefore a domain label that holds the local part of an email address should not be encoded/decoded. Sorry for the noise.

CL https://golang.org/cl/28961 mentions this issue.

CL https://golang.org/cl/29072 mentions this issue.

CL https://golang.org/cl/29071 mentions this issue.

CL https://golang.org/cl/29110 mentions this issue.

What is the status here? Is this going to be part of Go 1.8? What is left?

Are there any decisions remaining here or is it just all implementation? Assuming the latter.

Per earlier chat with @ianlancetaylor, we're going to make net.Dial work too before this is closed. That's easy. I'll do it soon.

Actually, I forgot why we might not want to do this in net: case folding Unicode domain names brings in the unicode package and tables, which is prohibited by the go/build deps_test.go policy.

I think we might just want to keep this in net/http for Go 1.8.

I'll keep this bug open until I add some more tests (around case folding), and then we'll call it good for Go 1.8.

CL https://golang.org/cl/29860 mentions this issue.

CL https://golang.org/cl/29859 mentions this issue.

@minux, perhaps. But feels slightly odd. We kinda do that for DNS if you include cgo, but that's pretty explicit. I'd rather consider that later, in Go 1.9. I have other things to focus on during 1.8.

In order to store URL's they need to be normalized. If I read all this correctly, then the following is still required to normalize URLs even in 1.8 correct?

    u, err := url.Parse(urlString)
    if err != nil {
        fmt.Println(err)
    }
    u.Host, err = idna.ToASCII(u.Host)
    if err != nil {
        fmt.Println(err)
    }
    u.Host, err = idna.ToUnicode(u.Host)
    if err != nil {
        fmt.Println(err)
    }

    fmt.Println(u)