International and Unicode domain names

[daidoji]

To be compatible with did:web and did-core I added this PR to match did:web. #114 for did:webs

However, due to KERI and AIDs in general mitigating (in theory) a lot of the issues that make homograph attacks possible we could explore future versions of this spec that provide explicit canonicalization schemes for unicode domain names without losing our compatibility to did:web. Not sure how feasible or if everyone thought this might be in scope (probably not for this current edition of the spec we're trying to get out) but thought I'd open the discussion as a placeholder for anyone who may be interested in the future.

[2byrds]

From our meeting:
It does seem that our approach would allow us to include intl/unicode domain names.

[dhh1128]

I did original research and gave a talk about homograph attacks at RSA 2016. This is a subject that I used to know a lot about, although it is possible that my knowledge is now stale, or that it was incomplete even back in the day. But I wanted to chime in on this, based on what I knew, because I think some increased precision is desirable. What did:web said isn't wrong, and neither is the conclusion that @2byrds recorded. However, I think we should document the reasoning more, and tweak the words in the spec slightly.

Here's my (possibly incorrect) understanding:

1. Domain names and domain path components have different rules with respect to how non-ASCII characters are encoded. In domain names, such characters are represented with PunyCode, whereas in the rest of a URL, they are percent-encoded. Thus, if I take the English name "acme" and replace the first letter (ASCII "a") with a visually identical Cyrillic "a"), and then put it in a domain name, it is encoded as xn--cme-5cd, but if I put this into the path portion of a URL, it becomes %D0%B0cme.

2. As already noted in the PR from @daidoji , DID core syntax is compatible with RFC 3986 (URIs), but not with RFC 3987 (IRIs). However, this does not mean that DIDs can't "support unicode characters" (the verbiage from the did:web method). ASCII characters ARE unicode characters, and we certainly support ASCII. DIDs also support punycode- and percent-encoded characters, which allows us to represent the full unicode range the same way any RFC3986-compliant URL would. So it would be more accurate to say "DID core can only support non-ASCII characters via the same punycode and percent encoding rules that standard URLs use."

3. As implied by the suffix "-graph", a homograph attack is about making someone misunderstand an IRI based on characters with similar appearance. This misunderstanding is only a risk because browsers choose to display IRIs instead of URLs in some places. This rendering is crucial/convenient for users of non-ASCII character sets, but also lossy for humans. Depending on which browser we are talking about, and which visual context we are talking about (URL bar, status message, popup tooltip), we might see xn--cme-5cd in a domain name rendered as ugly ASCII or as deceptively ASCII-looking "аcme". (It is also conceivable that we might see %D0%B0cme rendered as "аcme", but I believe this is less common, for various reasons. It is also less relevant to trust questions, because it is the domain name that generally [and unsafely] carries trust on today's internet.)

Since no browsers are currently coded to specially render did:webs values as IRIs in their UIs, and since our algorithm for generating did:webs values requires URLs rather than IRIs as input, strings converted to did:webs values will never appear with the friendly and possibly deceptive glyphs that enable a homograph attack. Imagine that an attacker wants someone to think they're dealing with acme.com at https://acme.com/path/aid. They replace the first letter in the company name with a Cyrillic "a". This creates the following URL that can be fetched by any HTTP client: https://xn--cme-5cd.com/path/aid. A careless user who sees this URL in some places in their browser might see an IRI that looks like the innocent https://acme.com/path/aid instead. A user can also paste an IRI into their URL bar. But either way, the IRI is NOT how the remote resource is fetched. What is processed by CURL, postman, python's requests library, and all other client software on the internet is still the ugly ASCII URL value, not the IRI. And did:webs has the same requirement. So the did:webs representation of the deceptive URL is did:webs:xn--cme-5cd.com:path:aid. Because did:webs doesn't render homographs to something that is visually identical, it has no direct vulnerability to homograph attacks. (And neither does did:web.)

If that were the whole story, I would say that both did:web and did:webs don't actually need the section that this PR included. However, I think it is still a worthwhile addition, because A) these DID methods can be superspreaders of a homograph attack, even though they themselves can never suffer from the virus and B) who knows whether browsers will at some future date start rendering DIDs as IRIs; C) the DID core spec might be updated to support IRIs.

If you buy this reasoning, I will submit a trivial PR that changes the verbiage about "can't support unicode" to something more accurate, and that clarifies that did:webs can't embody homograph attacks but can contain URLs that enable homograph attacks in other contexts.

[2byrds]

Amazing insight/detail @dhh1128 thank you for taking the time to breakdown the elements. I'm supportive of the updated wording. What do you think @daidoji ?

[daidoji]

@2byrds @dhh1128 yeah likewise, I knew about the mechanism about the attack but not the background in such detail. Thanks for writing all that up.

I guess the two main takeaways for me are 1. Yeah lets add more detail short of "we don't support unicode" as we've had a request for more rigor in the spec and 2. my idea that maybe we could figure out a way not to propagate homograph attacks using the did:webs maybe wasn't entirely justified. Glad to close this with spec update clarifications as I'm pretty convinced.

[daidoji]

Closed per above.