I'm going to retract my earlier proposal that we address this issue. While the idea of better aligning the challenges is aesthetically appealing, there seems to be agreement that there's not a major security issue here. And the spec has already passed WGLC with the existing set of challenges.
So I would propose that we close this issue and PR #312 ( https://github.com/ietf-wg-acme/acme/pull/312), which implements one solution. If there is a continued desire to do work here, a follow-on spec could define a harmonized set of challenges. Chairs: What say ye? --Richard On Sat, Jun 17, 2017 at 10:55 AM, Ilari Liusvaara <[email protected]> wrote: > 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
