On Wed, Jun 14, 2017 at 09:23:59AM -0400, Richard Barnes wrote:
> Hey Ilari,
>
> Thanks for this analysis. I agree that a tighter and clearer binding of
> the challenge/response pair to the validation transaction would be
> desireable, as would more uniformity across challenges. I would like to
> propose a slightly different structure, though.
>
> ===
>
> The essential elements of a challenge are (1) the content of the challenge,
> (2) the content of the response, (3) the content of the validation query,
> and (4) the content of the validation response (where in 3 and 4, we mean
> the part that is specific to the validation, vs. .well-known or
> _acme-challenge). Right now, (1) and (2) are the same for all challenges,
> but (3) and (4) differ.
>
> http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization
> tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization)
> dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization)
>
> I think we could meet the requirements above with the following steps:
>
> 1. Update the keyAuthorization structure to be a JSON object binding the
> validation to a bunch of stuff, e.g.:
>
> {
> "identifier": {"type": "dns", "value": "example.com"},
> "method": "dns-01",
> "key": { ... },
> "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
> }
>
> 2. Have the client provide the serialized keyAuthorization in its response
> to the challenge (in ACME) and have the server verify that it decodes
> properly, has only the identified fields, and the fields have the proper
> values.
This has the raw key, which means one has to compare raw keys. IIRC,
that is somewhat frowned on.
> 3. Derive the validation query and response values from the serialized
> keyAuthorization value provided in the response, using a "reveal the
> preimage" pattern, either:
> 3.a. query = H(kA), response=kA, or
> 3.b. query = H(H(kA)), response=H(kA)
>
> I kind of like the latter better, because it meets all the transport
> requirements for DNS and TLS (since the hashes are small). It also enables
> the server to verify that a challenge/response pair is valid without
> necessarily revealing to the server the details of the validation; if the
> server really wants to know, it can demand the raw key authorization.
I expect the most common check is check for identifier.
But being able to calculate where the response goes from the key
authorization (e.g.
'http://somehost3.example.net/.well-known/acme-challenge/yeag2...',
'_acme-validation.somehost3.example.net' or
'gesc3<...>.token.acme.invalid') is sure nice to have.
> That would give us a uniform structure across challenges:
>
> all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4)
> H(keyAuthorization)
I don't think there is any extra space in DNS for the query. IIRC,
there is 255 byte total length restriction for DNS QNAMEs in addition
to the 63 byte per-component limit.
> What would folks think of that? It's a large-ish change for this stage of
> the process, but it seems like the regularity it provides will help
> simplify analysis and make implementation easier, so I'm inclined to do it.
-Ilari
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
