Draft: draft-ietf-tls-esni

Commentary: Also , rename configdigest to configid to avoid confusion with cryptographic hash digests . cc 
 It 's bound by the size o the HPKE KDF output size , which is unlikely to be larger than 32B. Let 's make this : 
 We should also add a requirement for the HPKE ciphersuite . E.g. , ' Nh < = 2 ^ 8 ` . 
 ( Careful with fenceposts : . ) If config_digest is the output of a KDF , why could you not fix the length to something that is enough to avoid collisions ( 16 bytes seems ample for this ) and not worry about Nh at all ? 
 I think it makes sense to let the KDF dictate the security level , i.e. , the collision probability of the configdigest . 
 I would argue that collision probability here does n't contribute to security . If a config is misidentified , the result will be failure , not a reduction in security . A failure either because the group does n't match or because peers end up disagreeing on keys . 
 True that it 's an operational consideration rather than a security one . I still think it makes sense to let the length of be dictated by the KDF , since whether truncation is an operational risk depends on the KDF . 
 I assume here that a KDF is capable of producing uniform random bytes of arbitrary length , meaning that truncation is n't a factor . That 's what is for , right ? 
 That assumption holds if the input has sufficient entropy . Since the public key is public , there 's no entropy from the point of view of an adversary who wants to distinguish the output from random . 
 ( To be clear , I think truncating to something reasonable , like 16 bytes , is low risk . I would be fine with doing this . )
Paragraph (version B):
The configuration identifier, equal to "Expand(Extract("",
config), "ech_config_id", Nh)", where "config" is the "ECHConfig"
structure and "Extract", "Expand", and "Nh" are as specified by
the cipher suite KDF.  (Passing the literal """" as the salt is
interpreted by "Extract" as no salt being provided.)  The length
of this value SHOULD NOT be less than 16 bytes unless it is
optional for an application; see optional-configs.
Paragraph (version A):
Compare ClientEncryptedCH.config_digest against digests of known
ECHConfig and choose the one that matches.
Paragraph (version A):
Some uses of ECH, such as local discovery mode, may omit the
ClientEncryptedCH.config_digest since it can be used as a tracking
vector.  In such cases, trial decryption should be used for matching
ClientEncryptedCH to known ECHConfig.  Unless specified by the
application using (D)TLS or externally configured on both sides,
implementations MUST use the first method.
Paragraph (version B):
Compare ClientEncryptedCH.config_id against identifiers of known
ECHConfig and choose the one that matches.
Paragraph (version B):
Some uses of ECH, such as local discovery mode, may omit the
ClientEncryptedCH.config_id since it can be used as a tracking
vector.  In such cases, trial decryption should be used for matching
ClientEncryptedCH to known ECHConfig.  Unless specified by the
application using (D)TLS or externally configured on both sides,
implementations MUST use the first method.
Paragraph (version A):
Note that an unrecognized ClientEncryptedCH.config_digest value may
be a GREASE ECH extension (see grease-extensions), so it is necessary
for servers to proceed with the connection and rely on the client to
abort if ECH was required.  In particular, the unrecognized value
alone does not indicate a misconfigured ECH advertisement
(misconfiguration).  Instead, servers can measure occurrences of the
"ech_required" alert to detect this case.
Paragraph (version B):
Note that an unrecognized ClientEncryptedCH.config_id value may be a
GREASE ECH extension (see grease-extensions), so it is necessary for
servers to proceed with the connection and rely on the client to
abort if ECH was required.  In particular, the unrecognized value
alone does not indicate a misconfigured ECH advertisement
(misconfiguration).  Instead, servers can measure occurrences of the
"ech_required" alert to detect this case.
Paragraph (version A):
Client-facing server configuration determines the size of the
anonymity set.  For example, if a client-facing server uses distinct
ECHConfig values for each host, then each anonymity set has size k =
maximize the size of the anonymity set where possible.  This means
client-facing servers should use the same ECHConfig for as many hosts
as possible.  An attacker can distinguish two hosts that have
different ECHConfig values based on the
ClientEncryptedCH.config_digest value.  This also means public
information in a TLS handshake is also consistent across hosts.  For
example, if a client-facing server services many backend origin
hosts, only one of which supports some cipher suite, it may be
possible to identify that host based on the contents of unencrypted
handshake messages.
Paragraph (version B):
Client-facing server configuration determines the size of the
anonymity set.  For example, if a client-facing server uses distinct
ECHConfig values for each host, then each anonymity set has size k =
maximize the size of the anonymity set where possible.  This means
client-facing servers should use the same ECHConfig for as many hosts
as possible.  An attacker can distinguish two hosts that have
different ECHConfig values based on the ClientEncryptedCH.config_id
value.  This also means public information in a TLS handshake is also
consistent across hosts.  For example, if a client-facing server
services many backend origin hosts, only one of which supports some
cipher suite, it may be possible to identify that host based on the
contents of unencrypted handshake messages.
Paragraph (version A):
Optional record digests may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the
client-facing server in the "encrypted_client_hello" extension.  In
such settings, clients send either an empty config_digest or a
randomly generated config_digest in the ClientEncryptedCH.  (The
precise implementation choice for this mechanism is out of scope for
this document.)  Servers in these settings must perform trial
decryption since they cannot identify the client's chosen ECH key
using the config_digest value.  As a result, support for optional
record digests may exacerbate DoS attacks.  Specifically, an
adversary may send malicious ClientHello messages, i.e., those which
will not decrypt with any known ECH key, in order to force wasteful
decryption.  Servers that support this feature should, for example,
implement some form of rate limiting mechanism to limit the damage
caused by such attacks.
Paragraph (version B):
Optional configuration identifiers may be useful in scenarios where
clients and client-facing servers do not want to reveal information
about the client-facing server in the "encrypted_client_hello"
extension.  In such settings, clients send either an empty config_id
or a randomly generated config_id in the ClientEncryptedCH.  (The
precise implementation choice for this mechanism is out of scope for
this document.)  Servers in these settings must perform trial
decryption since they cannot identify the client's chosen ECH key
using the config_id value.  As a result, support for optional
configuration identifiers may exacerbate DoS attacks.  Specifically,
an adversary may send malicious ClientHello messages, i.e., those
which will not decrypt with any known ECH key, in order to force
wasteful decryption.  Servers that support this feature should, for
example, implement some form of rate limiting mechanism to limit the
damage caused by such attacks.