domain separation

draft-irtf-cfrg-hash-to-curve.md

@@ -952,6 +952,30 @@ In contrast, this document is concerned with encodings from arbitrary bit string
 to elliptic curve points.
 This document does not cover serialization or deserialization.
 
+### Domain separation {#term-domain-separation}
+
+In most cases, cryptographic protocols that use random oracles are analyzed
+under the assumption that the random oracle answers only queries generated
+by that protocol.
+In practice, this assumption may not hold: commonly, two or more protocols
+may model the same hash function as a random oracle, which violates the above
+assumption if both protocols compute the hash of the same value.
+
+A common approach to addressing this issue is called domain separation,
+which allows a single random oracle to simulate multiple, independent oracles.
+This is effected by ensuring that each simulated oracle sees queries that are
+distinct from those seen by all other simulated oracles.
+For example, to simulate two oracles R1 and R2 given a single oracle R,
+one might define
+
+    R1(x) := R("R1" || x)
+    R2(x) := R("R2" || x)
+
+In this example, "R1" and "R2" are called domain separation tags.
+Because of these domain separation tags, R1 and R2 cannot query R on
+overlapping values.
+Thus, it is safe to treat them as independent oracles.
+
 # Roadmap {#roadmap}
 
 This section presents a general framework for encoding bit strings to points
@@ -984,7 +1008,7 @@ Input: alpha, an arbitrary-length bit string.
 Output: P, a point in G.
 
 Steps:
-1. u = hash_to_base(alpha, 0)
+1. u = hash_to_base(alpha, 2)
 2. Q = map_to_curve(u)
 3. P = clear_cofactor(Q)
 4. return P
@@ -1015,6 +1039,47 @@ Instances of these functions are given in {{suites}}, which defines a list of
 suites that specify a full set of parameters matching elliptic curves and
 algorithms.
 
+## Domain separation requirements {#domain-separation}
+
+When invoking hash\_to\_curve, implementors MUST use domain separation
+({{term-domain-separation}}) to avoid interfering with other protocols
+that also use the hash\_to\_curve functionality.
+In addition, any protocol that uses two or more hash\_to\_curve functions
+targeting different elliptic curves MUST enforce domain separation between
+the two functions if those functions are modeled in the protocol as
+independent random oracles.
+Finally, protocols that use encode\_to\_curve SHOULD use domain separation
+if possible, but it is not required in this case.
+
+Care is required when choosing a domain separation tag.
+Implementors SHOULD observe the following guidelines:
+
+1. Tags should be prepended to the value being hashed, as in the example
+   in {{term-domain-separation}}.
+
+2. Tags should have fixed length, or should be encoded in a way that makes
+   the length of a given tag unambiguous.
+   If a variable-length tag is used, it should be prefixed with a
+   fixed-length field that encodes the length of the tag.
+
+3. Tags should begin with a fixed protocol identification string.
+   Ideally, this identification string should be unique to the protocol.
+
+4. Tags should include a protocol version number.
+
+5. For protocols that support multiple ciphersuites, tags should include
+   a ciphersuite identifier.
+
+As an example, consider a fictional key exchange protocol named Quux.
+A reasonable choice of tag might be "QUUX-V\<xx\>-CS\<yy\>", where \<xx\> and \<yy\>
+are two-digit numbers indicating the version and ciphersuite, respectively.
+
+Alternatively, if a variable-length ciphersuite string must be used,
+a reasonable choice of tag might be "QUUX-V\<xx\>-L\<zz\>-\<csid\>", where
+where \<csid\> is a the ciphersuite string, and \<xx\> and \<zz\> are
+two-digit numbers indicating the version and the length of the ciphersuite
+string, respectively.
+
 # Utility Functions {#utility}
 
 Algorithms in this document make use of utility functions described below.
@@ -1217,14 +1282,14 @@ Parameters:
 
 Inputs:
 - msg is the message to hash.
-- ctr is either 0 or 1.
+- ctr is either 0, 1, or 2.
   This is used to efficiently create independent
   instances of hash_to_base (see discussion above).
 
 Output: u, an element in F.
 
 Steps:
-1. m' = H(msg) || I2OSP(ctr, 1)
+1. m' = "HASH-TO-CURVE" || H(msg) || I2OSP(ctr, 1)
 2. for i in (1, ..., m):
 3.   t = ""     // initialize t to the empty string
 4.   for j in (1, ..., W):
@@ -2028,13 +2093,16 @@ This document has no IANA actions.
 
 # Security Considerations
 
-Each encoding function variant accepts arbitrary input and maps it to a pseudorandom
+Each encoding function accepts arbitrary input and maps it to a pseudorandom
 point on the curve.
 Directly evaluating the mappings of {{mappings}} produces an output that is
 distinguishable from random.
 {{roadmap}} shows how to use these mappings to construct a function approximating a
 random oracle.
 
+{{domain-separation}} describes considerations related to domain separation
+for random oracle encodings.
+
 {{hashtobase}} describes considerations for uniformly hashing to field elements.
 
 # Acknowledgements