Post on 18-Jan-2016
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