On Sat, Jun 17, 2017 at 08:47:23AM -0500, Logan Widick wrote: > Would it be possible to add a section for how to follow this pattern in the > presence of space constraints? > > One possible way would be to divide H(H(kA)) and H(kA) into N pieces as > needed to get through the system. Each request would include the "piece > number" in some way so that the system can work even in the (probably rare) > event that pieces of either H(H(kA)) or H(kA) are identical. The ACME > server would make N requests (one for each of the N pieces). If N=1, the > piece number would be omitted and only 1 request would be made. In the > event of failure, the problem document could indicate the failing pieces in > an array.
The even you call "probably rare" is in fact extremely unlikely. Even under deliberate manipulation trying to make it happen. In fact, if |kA| != |H(x)|, finding any such kA breaks the hash function outright. There are two places which have space constraints: - DNS QNAME: Eating challenge space in addition to what already needs to be there is pretty harsh. Additionally, adding challenge there would break delegated setups. - TLS certificate SAN names: The DNS 63 byte limit for name component may be relevant. Can be worked around by inserting a period in the middle of the challenge / response. The DNS name limit is not relevant: The postfixes are fixed, limiting the name to 85 bytes or so. The primary reason for having challenge is for the target to find the response(s) to return. In case of HTTP or TLS-SNI, returning multiple responses at once is highly problematic (demultiplexing requests problem). Not so with DNS: It can easily return multiple responses at once (up to around 18 without fallback, around 1000 with fallback to TCP). And the reason for having the challenge and response be (statistically) different is prevent careless servers from just copying the challlenge to response and passing validation. TLS-SNI-01 has that problem (HTTP-01 does not, due to the account thumbprint being added). > That way, the same pattern works regardless of space constraints. > > As for key comparison, here are some ideas: > 1. Put the key thumbprint (produced using the same hash function H > specified in the challenge) in the revised key authorization structure in > lieu of the key. Include the key ID as another field in the key > authorization structure. > > 2. Require that only a given subset of JWK fields appears (like the fields > required for thumbprints). Include the key ID as another field in the key > authorization structure. Doesn't that put the same information in two places (which is legendary source of all sorts of problems)? Computing thumbprints and comparing those does not detect keys that are different as the same, but can detect the same keys as different (due to noncanonical representations. However, those are either illegal JWKs, or just crazy, like RSA key with e > n). -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
