IDNAbis and Security Protocols or Internationalization Issues with Short Strings

1. IDNAbis and Security ProtocolsorInternationalization 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