1. IDNAbis and Security Protocols or Internationalization Issues with Short Strings John C Klensin SAAG – 26 July 2007

2. IDNA as a Learning Experience Went out into unknown territory; inevitably learned some things Today’s talk will –Review what we learned –Summarize IDNAbis objectives and directions –Examine implications of the learning experience to security protocols

3. Some Lessons This group is not comprehensive Not IDNA-specific There are others

4. Expanding Standards ASCII (and ISO8859-1, 2, etc) are closed sets –All code points and characters allocated initially –No real need to deal with versioning Unicode grows This turns out to be more important than we realized

5. The Version/ Library Fallacy IDNA2003 and Stringprep assume –Unicode 3.2 –Revision for future versions –Implementations stable at 3.2 Applications call libraries –Libraries for Unicode migrating into OS –Version you get is the version you get –Even if API delivers version number, not useful So “version agnostic” isn’t a goal but a necessity

6. Good Behavior Assuming that everyone will follow the rules consistently is a bad idea –Don’t need to tell the security community that –Millions of zones/ “registries”, not a dozen or 250. Can’t find the Protocol Police

7. Exclusion Include everything unless you have a reason not to –Bad idea for expanding standards –Creates a lot of pressure to not have such reasons Compatibility mappings seemed like a good idea… for a while

8. Spoofing Look-alike and Confusable Characters Nothing new –0O, 1l –But lots more dramatic with large character collections –Note that a careful choice of fonts makes things less (or more) confusing No protocol or procedural fix –Can avoid making things worse than they need to be… and should –But largely a UI and User Awareness 1issue

9. Single Profile Applications are different –Different needs –Different profiles –Best character set for identifiers may not be best for passwords We knew this five years ago… And then proceeded, sometimes, to behave as if we didn’t

10. Words and Orthography “Words” have never been an expectation in the DNS IETF knows this; community keeps losing track New stress on –Mnemonics –No “right” to use particular strings in the DNS

11. IDNAbis Protocol has fewer variations User conveniences are a UI matter –No compatibility mappings –No case mappings –Prohibition of anything that IDNA2003 maps out –Inclusion, rather than exclusion of characters –Prohibition of “non-language” characters, symbols, punctuation,… Unassigned code points are banned –Can’t write rules for them

12. Character Classification, Not Tables as Specification Unicode Categories and Properties used to construct IDNA categories of characters combined to form IDNA rule-groupings applied differently for registration lookup / resolution

13. The Rule-Groupings Always Maybe Yes Maybe No Contextual Rule Required Never (and unassigned)

14. Registration Always Possibly Maybe Rule iff it exists and is valid Registry-imposed restrictions permitted and expected

15. Resolution Look up unless… –Never –Unassigned –Rule doesn’t exist –Rule fails The really dangerous cases will not be looked up even if they are registered (in violation of the protocol)

16. Other Changes Terminology: A-labels and U-labels Contextual rules permit some extra (and important) characters BIDI fixes

17. Surroundings No changes to Stringprep –(although you might want to make some) A DNS-embedded label that is valid today under protocol and all guidelines –Stays valid –Alternate forms in which that label could be written are generally prohibited –Some new labels permitted (including new scripts)

18. The Security Lessons First, IDNAbis does not require changes Some changes may be wise –Mostly on the basis of dealing with recently- understood risks Interoperability problems are different from Confusion problems –Usually neither are desirable –Protocol-level interoperability may be different from inter-user interoperability –For passwords and passphrases, controlled confusion may be an advantage

19. Serious Work to Get Thing Right Examine actual strings and uses –Generally, less variation is good –Some things may need to be more restricted than others When dealing with domain names –Usually will want to use A-labels in protocols and databases, with U-labels only as user mnemonics –There may be exceptions

20. Layering is Often Good Internationalization as a tool for Localization Be careful about getting tied up with “language” –Sometimes very important and necessary –But it introduces new problems and issues If exact comparisions (or rejection) are needed, don’t make that harder than needed.

21. Summary This needs to be done Changes in IDNA do not affect possible security changes and don’t need to be sequenced with them. Striving for simplicity and few options will make life better