Subject: [Acme] HTTP and DNS Challenge string

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 09:42:38 +0100

hello, I have a little proposal:

https://github.com/ietf-wg-acme/acme/issues/88

in short, I see not THAT much reason to use a completely random string for
the challenges, I think it would be better to just use your account key.
the only thing random keys are is increase annoyance when you cannot work
automatically (try manually posting 14 challenges from SSH to your web
folder and you'll get my point)

my Idea is that instead of a random string you rather use your account key
(or a hash of it) as the challenge. with that you dont always have to
create and delete challenge records because you can just let it stay there
which essentially also lowers the strain of DNS Servers during renewal
times (in case of DNS validation)

also the servers of the ACME-CA will also have less strain because they
dont need to send extra challenges and check those, because the possession
of the key is already proven because it needs to sign every request to the
ACME protocol, that's why it makes sense to just use the esatblished
identity instead of establishing something completely new and then linking
it. They just need to download the key file/records and check whether the
key we want is inside

also when you want to create a SAN cert with http challenge for multiple
webroots you can just copypaste the same file to all webroots and the
automation doesnt have to worry about anything else.

best regards.

---

From: Thomas Lußnig <[email-masked]>
Date: Mon, 21 Mar 2016 10:29:03 +0100

Hi Philipp,

why not switch the handling.
Publish the Fingerprint of your public Key in DNS/WEB.
And the challenge is then to sign the random value with your public key.
This would also speed up the whole process. Since the acme server
can get the pub key when you request the domain and check than your 
response.
And not you tell him check the webpage now and wait till he checked the 
page.

Gruß Thomas

Am 21.03.2016 um 09:42 schrieb Philipp Junghannß:
> in short, I see not THAT much reason to use a completely random string 
> for the challenges, I think it would be better to just use your 
> account key.
> the only thing random keys are is increase annoyance when you cannot 
> work automatically (try manually posting 14 challenges from SSH to 
> your web folder and you'll get my point)
>
> my Idea is that instead of a random string you rather use your account 
> key (or a hash of it) as the challenge. with that you dont always have 
> to create and delete challenge records because you can just let it 
> stay there which essentially also lowers the strain of DNS Servers 
> during renewal times (in case of DNS validation)
>
> also the servers of the ACME-CA will also have less strain because 
> they dont need to send extra challenges and check those, because the 
> possession of the key is already proven because it needs to sign every 
> request to the ACME protocol, that's why it makes sense to just use 
> the esatblished identity instead of establishing something completely 
> new and then linking it. They just need to download the key 
> file/records and check whether the key we want is inside
>
> also when you want to create a SAN cert with http challenge for 
> multiple webroots you can just copypaste the same file to all webroots 
> and the automation doesnt have to worry about anything else.
>
> best regards.
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 10:34:04 +0100

I didnt even specify a direct order in the first place but the client could
tell the user on how to do the stuff if there is no key. pre-publishing is
one of the reasons for this since it also allows you to delegate a
subdomain to someone else in DNS challenge without having to wait for a
challenge.

also you even need to sign an extra random value because it should probably
have signed one when trying to request the cert so they can just check for
the records/keyfile and compare the signature.

regards.

2016-03-21 10:29 GMT+01:00 Thomas Lußnig <[email-masked]>:

> Acme mailing [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>
>

---

From: Thomas Lußnig <[email-masked]>
Date: Mon, 21 Mar 2016 11:03:29 +0100

Currently

1) Client->Server Request(domain.xy) => Response(nonce to be signed)
--> Server fetch CAA record
2) Client->Server Request(Please check via dns/http)
--> Server check resouce
3*) Client->Server Is the Check complete(Please check via dns/http)

My Idea

1) Client->Server Request(domain.xy) => Response(nonce to be signed)
--> Server fetch CAA record + DNS(acme.pubkey.domain.xy) to get the PIN 
of account key
2) Client->Server Request(Signed nonce with private key, Public Key) => 
Response(Sucess/Failed)

Am 21.03.2016 um 10:34 schrieb Philipp Junghannß:
> to sign an extra random value because it should probably have signed 
> one when trying to request the cert so they can just check for the

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 11:05:22 +0100

that should pretty much what it will be about.

2016-03-21 11:03 GMT+01:00 Thomas Lußnig <[email-masked]>:

> --> Server fetch CAA record + DNS(acme.pubkey.domain.xy) to get the PIN of
> account key
>> to sign an extra random value because it should probably have signed one
>> when trying to request the cert so they can just check for the
>>
>
>

---

From: Alan Doherty <[email-masked]>
Date: Mon, 21 Mar 2016 12:22:19 +0000

im fairly certain the interactive nature of the acme protocol is a designed security feature, not flaw

as ground up its entirely directed at automated use, thus the short ttl on certs
(and the ephemeral nature of authenticator tokens)

if pre-setup of authentication credentials was possible it introduces a potential flaw :
example 
malicious hacker gets his bag of tools to insert his authenticator onto all compromised sites, into any zones on compromised cpanels in isps etc
then at leisure obtains valid certs to run mitm attacks from any locations possible to any of those sites
never gets found out about as the credentials don't expire and few actively look at their dns or would notice a suspect record, let walk the directory tree on their website

i have to copy the authenticators to multiple webroots on multiple servers (as we cdn all sites across multiple servers/locations) and thus cant guess which one will see the authenticators get request

but as the tools are open source and easily altered/modified we cp the token to the webroot and scp to all the other servers in the script with no real issues (we use the https://github.com/lukas2511/letsencrypt.sh tool)

anyone running manual mode should look at a 3rd party option in a language they are happy with and make the mods the need to make it compatible with their setup 

At 10:05 21/03/2016  Monday, Philipp Junghannß wrote:
>2016-03-21 11:03 GMT+01:00 Thomas Lußnig <<mailto:[email-masked]>[email-masked]>:
>Currently
>
>--> Server fetch CAA record + DNS(acme.pubkey.domain.xy) to get the PIN of account key
>2) Client->Server Request(Signed nonce with private key, Public Key) => Response(Sucess/Failed)
>
>
>
>
>to sign an extra random value because it should probably have signed one when trying to request the cert so they can just check for the
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 21 Mar 2016 18:51:16 +0200

> folder and you'll get my point)

Yes, I agree that using account keys would be better. However, the CA
requirements (set by CAB Forum) for validation either require:

- Random string
- Hash of final key to issue (which wouldn't work in ACME due to
  authorize-issue design).

-Ilari

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Mar 2016 15:36:49 -0400

Having the token also lets the validation server operator specify which
names the key is being authorized for.  I might have virtual hosting box
with 200 names on it; I don't want to authorize any given key for all of
them.

On Mon, Mar 21, 2016 at 12:51 PM, Ilari Liusvaara <[email-masked]>
wrote:

> for

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 21 Mar 2016 21:43:54 +0200

> with 200 names on it; I don't want to authorize any given key for all of

Huh? Aren't authorization lookups inherently per-name (outside ones
specifically desinged to cover multiple names), so admins/servers can
authorize keys on per-name basis?

-Ilari

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 20:48:44 +0100

there are iirc no multi name http-01 and dns-01.
you have to do each one on its own.

---

From: Jonathan Leroy - Inikup <[email-masked]>
Date: Mon, 21 Mar 2016 21:13:29 +0100

> folder and you'll get my point)

With most of web servers, you can use a location regex to
automatically answer challenges.
E.g. with Nginx :

location ~ ^/\.well-known/acme-challenge/(?<filename>[-_a-zA-Z0-9]+)$ {
    default_type text/plain;
    return 200 '$filename.YOUR_ACCOUNT_THUMBPRINT';
}

-- 
Jonathan Leroy
http://www.inikup.com/
Tel: +33 (0)9 74 77 41 72

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Mar 2016 16:13:31 -0400

> authorize keys on per-name basis?

Sort of.  The query does specify the name (as Host header or QNAME), but
you can certainly imagine scenarios where people make symlinks or CNAMEs
for convenience, and that would have bad consequences if the challenge
response is not specific to an authorization transaction.

Likewise, you could imagine that a website owner might want some control on
which CAs issue (beyond CAA), and the transaction binding (via the token)
also provides that.

--Richard