Subject: Re: [Acme] Challenge objects are provoking implementation mistakes

From: Daniel McCarney <[email-masked]>
Date: Thu, 1 Mar 2018 09:48:16 -0500

This thread and the PR have been open since early Jan.

Sophie, Jacob, Richard Barnes (OOB), and myself were supportive.

I'm going to resolve conflicts and merge this PR today.

Thanks all,

- Daniel / cpu

On Wed, Jan 3, 2018 at 7:04 AM, Sophie Herold <[email-masked]>
wrote:

> Hi,
>
> small note on my changes: I might have changed the meaning of
> 'fulfilling' and 'responding to' a challenge. I think these terms will
> be relevant for clarifying other outstanding issues. Therefore, I would
> like to settle on some terms that will be used throughout the standard.
>
> fulfilling a challenge:
>   e.g. client provisioning a TXT record
>
> responding to a challenge:
>   posting to the challenge url (the server can try validation now)
>
> Best,
> Sophie
>
> On 02/01/18 20:51, Daniel McCarney wrote:
> > Thanks for the PR Sophie. I voiced a +1 on the Github thread but will
> also
> > echo it here.
> >
> > On Wed, Dec 27, 2017 at 8:35 AM, Sophie Herold <[email-masked]>
> > wrote:
> >
> >> Hi,
> >>
> >> I have posted a PR that implements both changes (not expecting and not
> >> returning the keyAuthorization) as basis for a discussion.
> >>
> >> https://github.com/ietf-wg-acme/acme/pull/375
> >>
> >> Notably, I think this should be backwards compatible for clients as far
> >> as we want it to be. The redundant keyAuthorization would just be
> >> ignored by the server.
> >>
> >> Best,
> >> Sophie
> >>
> >> On 21/12/17 04:07, Jacob Hoffman-Andrews wrote:
> >>> On 12/19/2017 03:10 AM, Sophie Herold wrote:
> >>>> If the client follows the schema
> >>>>
> >>>> 1. fulfill challenge
> >>>> 2. POST challenge URL
> >>>>
> >>>> it is unlikely that the keyAuthorization returned by the server would
> be
> >>>> used to fulfill the challenge (again).
> >>>>
> >>>> However, it should be possible to obtain a working ACME client by
> >>>> POSTing to the challenge URL first and using the keyAuthorization
> >>>> returned by the server (and possibly changed by the server) to fulfill
> >>>> the challenge afterwards. This should work since the servers challenge
> >>>> checks (DNS, HTTP, ...) are not instantaneous and even retried. In
> this
> >>>> case the MitM protection is bypassed by incautious client
> >> implementation.
> >>>
> >>> This is a good point. The other potential issue is reliability: a
> client
> >>> the depends on the returned keyAuthorization rather than the one it
> >>> provided might appear to work for a while, then stop working if the
> >>> server started validating challenges more quickly.
> >>>
> >>> I would support a change so that the server does not echo the
> >>> keyAuthorization. This brings up another question: Why have the client
> >>> include the keyAuthorization in the challenge POST at all? Both sides
> >>> can calculate it from scratch, the POST is essentially just "I'm ready
> >>> for validation now!" I think we originally included it because we
> >>> anticipated had other challenges where the client would be expected to
> >>> provide some secret token in the challenge response, or some proof of
> >>> control of a key, so including some payload (keyAuthorization) for the
> >>> other challenge types seemed stylistically consistent with that.
> >>> However, I don't think it's really necessary.
> >>>
> >>> _______________________________________________
> >>> Acme mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/acme
> >>>
> >>
> >> _______________________________________________
> >> Acme mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/acme
> >>
> >
> >
> >
> > _______________________________________________
> > Acme mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/acme
> >
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>