On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley wrote: > What do you mean they are weak sauce? Considering at least one of the > patents is claimed to cover the ACME challenge validations, they seem pretty > on-point.
I thought my comparison illustrated very well what I meant by weak sauce. People can _claim_ anything they want. Nothing I've seen in the patents comes close to achieving the desired confidence that the would-be subscriber is able to exert control over the FQDN to be validated. [ The remainder of this post might feel like it's picking on GoDaddy. But actually all the patents are awful, they're just serving as an illustration ] There are three ACME challenge validations in use today, two are already covered in Baseline Requirements document version 1.4.2. so that leaves only dns-01 which would be covered under the proposed 3.2.2.4.7 from Ballot 182 (and Ballot 169). GoDaddy claims US9183368 is relevant to 3.2.2.4.7 but they have not, so far as I've seen, claimed that US9183368 actually impacts the ACME dns-01 challenge. US9183368 is concerned with a "Pass String" which is analogous to the Random Value described in part of 3.2.2.4.7. The CA chooses a "Pass String", this is communicated somehow to the would-be subscriber, and then the CA checks whether it appears in a DNS TXT or CNAME record. That's it, validation done, That's what I mean by weak sauce. What did we validate? What are we sure about? Not very much. ACME's dns-01 challenges can't use a Random Value approach, it would not achieve the confidence we want that the would-be subscriber and whoever is fiddling with DNS are one and the same. Fortunately 3.2.2.4.7 also offers the possibility of using a Request Token rather than a Random Value so ACME does this: 1. the CA picks a random string containing at least 128-bits of entropy and tells the ACME client 2. the ACME client uses its private key (the ACME account key, not the private half of the key for an X.509 certificate) to sign a data structure containing the random string called a "key authorization" 3. the ACME client puts a base-64 encoded SHA256 digest of the key authorization in a DNS TXT record [there's your Request Token] 4. the ACME client sends the whole key authorization back to the CA 5. the CA checks the DNS TXT record, verifies that there's a digest inside, that the digest matches the provided key authorization, that the key authorization is signed by the ACME account key, and that the authorization is for the random string it chose in step 1. Only if all these checks pass is the FQDN validated for this ACME account. The "Pass String" idea is very simple, but it's wholly inferior in terms of the confidence that can be achieved. In particular, the Pass String is subject to a trivial MITM. Anyone who can convince me to perform US9183368 based validation can use that to pass other DNS-based validations, whether US9183368 or something else. So maybe I thought I was validating my domain for a new advertising network, or a government scheme, but instead I just validated their control of my domain to a CA and they're getting a certificate issued. Because the ACME approach uses public key crypto it can render a MITM ineffective. If Monika chooses to use her own ACME account key then she can't get the appropriate key authorization digest into the victim's DNS. If Monika instead lets the victim use their own ACME account keys, the digest will match up but Monika can't obtain a certificate because now the validation belongs to the victim. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
