version 1.00 UTF-8 dh:2011-07-11 PROPOSAL: ODF 1.3 PROTECTION-KEY ENHANCEMENTS ============================================= A. Rationale B. Proposed Changes 1. Front Page 2. Section 19.697 table:protection-key 3. Section 19.697 table:protection-key-digest-algorithm 4. Section 19.850 text:protection-key 5. Section 19.851 text:protection-key-digest-algorithm A. RATIONALE The use of password hashes in easily-discovered XML element and attribute values is subject to compromise of the hashed password. Although the use of increasingly-stronger digest algorithms may lengthen the time required for carrying out a brute-force attack on the hash, memorable passwords remain subject to compromise and the attack becomes easier as processor technology advances. In addition, the presence of hashes in plain sight in XML documents allows the digest value to be easily compared with the same digest value elsewhere, revealing worthy targets to an adversary. In addition, the digest value is easily removed/replaced. And an extracted digest value can be repurposed for malicious purposes. This proposal introduces two protection-key digest algorithms that are intended to mitigate (but not eliminate) risks associated with use of digest algorithms and provision of the digests in plain view in XML documents. The first algorithm defines a salting of the computation of SHA1 digest values. This increases the difficulty of detecting where the same password has been used in more than one place. It also may provide a slight increase in the difficulty of discovering the password by brute- force attempts against the salted-hash computation. The second algorithm is not specified beyond requiring that a password is not used to derive the protection-key value. This is the only means by which revealed protection-keys cannot be directly attacked in an effort to discover a password used in its creation, because there is no such password. The prospect that the protection-key value itself can be misused in some way remains. This proposal does not establish any conformance requirement on the use of the second algorithm. It establishes sufficient information for the introduction of such algorithms in practice and leaves open the arrange- ments that producers and consumers might introduce to make use of the second algorithm useful and appealing under practical conditions. Specification of these provisions in an early Committee Specification DRaft for ODF 1.3 secures an opportunity for experimental introduction in ODF 1.2 extended documents and confirmation of practical utility of the additonal algorithms. B. PROPOSED CHANGES (relative to OpenDocument-v1.2-cs01-part1) for ODF 1.3 CSD01 1. Front Page ---------- [Add to Declared XML Namespaces] http://docs.oasis-open.org/ns/office/1.3/protection# 2. Section 19.697 table:protection-key ----------------------------------- Change the paragraph "The password shall be provided as a sequence of bytes in UTF-8 encoding." to read "Any password shall be provided as a sequence of bytes in UTF-8 encoding." After that text, add the paragraph: "Consumers shall not silently ignore the presence of a table:protection-key attribute. A consumer that does not recognize or support the specified table:protection-key-digest-algorithm should not accept any password for release of the protection. Any other means for removal of a table:protection-key and the associated protection is implementation-defined." Change, by adjustment of the schema "The table:protection-key attribute has the data type string 18.2." to "The table:protection-key attribute has the data type base64Binary 18.2." 3. Section 19.697 table:protection-key-digest-algorithm ---------------------------------------------------- Insert before the paragraph beginning "Any other procedures ... ." the following paragraphs: "If the table:protection-key-digest-algorithm value is 'http://docs.oasis-open.org/ns/office/1.3/protection#sha1-salted' the value encoded in the table:protection-key value consists of the 20 octets of an SHA1 message digest followed immediately by 20 octets of a cryptographically-random salt value. The SHA1 message digest is prepared, in accordance with [xmlenc-core] section 5.7.1, from the message consisting of the octets of the UTF-8 password followed immediately by the octets of the salt value. "If the table:protection-key-digest-algorithm value is 'http://docs.oasis-open-org/ns/office/1.3/protection#secure160' the value encoded in the protection-key value consists of 20 octets (160 bits) of binary data not derived from an user-provided password. Any means by which consumers recognize the producer of the table:protection-key value and authenticate a request to remove the protection is implementation-dependent. [Note: The binary data can contain a cryptographically-random value. Use of a protection-key value that is not derived from a password avoids compromise of memorable passwords useful in attacking other digital assets such as encrypted documents. Protection-key attributes themselves are easily defeated by removing/replacing them directly in XML documents that contain them. XML-visible digest values are also amenable to repurposing for malicious purposes.] Replace the paragraph beginning "Consumers shall support ... ." with the following paragraph: "Consumers shall support htt://www.w3.org/2000/09/xmldsig#sha1, which is the default, http://www.w3.org/2001/04/xmlenc#sha256, and http://docs.oasis-open.org/ns/office/1.3/protection#sha1-salted. Producers should use http://docs.oasis-open.org/ns/office/1.3/protection#sha1-salted. Producers shall provide warnings that when a password is used as the basis of a protection-key setting, the password itself is compromisable." 4. Section 19.850 text:protection-key ---------------------------------- Change the paragraph "The password shall be provided as a sequence of bytes in UTF-8 encoding." to read "Any password shall be provided as a sequence of bytes in UTF-8 encoding." After that text, add the paragraph: "Consumers shall not silently ignore the presence of a text:protection-key attribute. A consumer that does not recognize or support the specified text:protection-key-digest-algorithm should not accept any password for release of the protection. Any other means for removal of a text:protection-key and the associated protection is implementation-defined." Change, by adjustment of the schema "The text:protection-key attribute has the data type string 18.2." to "The text:protection-key attribute has the data type base64Binary 18.2." 5. Section 19.851 text:protection-key-digest-algorithm --------------------------------------------------- Insert before the paragraph beginning "Any other procedures ... ." the following paragraphs: "If the text:protection-key-digest-algorithm value is 'http://docs.oasis-open.org/ns/office/1.3/protection#sha1-salted' the value encoded in the table:protection-key value consists of the 20 octets of an SHA1 message digest followed immediately by 20 octets of a cryptographically-random salt value. The SHA1 message digest is prepared, in accordance with [xmlenc-core] section 5.7.1, from the message consisting of the octets of the UTF-8 password followed immediately by the octets of the salt value. "If the text:protection-key-digest-algorithm value is 'http://docs.oasis-open-org/ns/office/1.3/protection#secure160' the value encoded in the protection-key value consists of 20 octets (160 bits) of binary data not derived from an user-provided password. Any means by which consumers recognize the producer of the text:protection-key value and authenticate a request to remove the protection is implementation-dependent. [Note: The binary data can contain a cryptographically-random value. Use of a protection-key value that is not derived from a password avoids compromise of memorable passwords useful in attacking other digital assets such as encrypted documents. Protection-key attributes themselves are easily defeated by removing/replacing them directly in XML documents that contain them. XML-visible digest values are also amenable to repurposing for malicious purposes.] Replace the paragraph beginning "Consumers shall support ... ." with the following paragraph: "Consumers shall support htt://www.w3.org/2000/09/xmldsig#sha1, which is the default, http://www.w3.org/2001/04/xmlenc#sha256, and http://docs.oasis-open.org/ns/office/1.3/protection#sha1-salted. Producers should use http://docs.oasis-open.org/ns/office/1.3/protection#sha1-salted. Producers shall provide warnings that when a password is used as the basis of a protection-key setting, the password itself is compromisable." *** end of proposal v1.00, 2011-07-11T21:50Z ***