IDNAbis and Security Protocolsor

Internationalization Issues with Short Strings

John C Klensin

SAAG – 26 July 2007

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

Some Lessons

• This group is not comprehensive

• Not IDNA-specific

• There are others

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

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

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

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

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

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

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

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

Character Classification, Not Tables as Specification

Unicode Categories and Properties used to constructIDNA categories of characters combined to formIDNA rule-groupings applied differently for registration lookup / resolution

The Rule-Groupings

• Always

• Maybe Yes

• Maybe No

• Contextual Rule Required

• Never (and unassigned)

Registration

• Always

• Possibly Maybe

• Rule iff it exists and is valid

• Registry-imposed restrictions permitted and expected

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)

Other Changes

• Terminology: A-labels and U-labels

• Contextual rules permit some extra (and important) characters

• BIDI fixes

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)

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

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

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.

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