Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Daniel McCarney <[e-mail]>]

Here's another PR with further feedback:
https://github.com/ietf-wg-acme/acme/pull/453

Replies in-line below.

> Perhaps dropping the "to clients" would remove the reading that
> there is nonce/client tracking without losing any significant information,
> but this seems to fall under editorial discretion, so it's all yours.

I think that's a reasonable change if it will reduce confusion. Done.

> How about "It is also used, with some media types, from certificate
> resources [...]"?

Works for me. Done.

> And my intent was to suggest that there is a new paragraph for
"alternate",
> maybe:

>> The "alternate" link relation is used when a CA can provide multiple
>> distinct certification chains (e.g., chaining to different root CA
>> certificates) for a provided certificate.

I don't think this is needed. Section 7.4.2 "Downloading the Certificate"
says
almost the same thing when describing the "alternate" relation. I think
this is
the location in-document where the information is most relevant.

> Ah. This table is slightly cramped, so it may not be worth a change, but
> even "order's certificate" (and the matching "order's authorizations")
> might help.

Ok, changed to the possessive forms.

> Mostly I just want the document to be clear and consistent about whether
> exactly one successful challenge suffices to authorize, and exactly one
> unsuccessful challenge suffices to fail authorization

Ok. I think this has been made clear in #447. One authorization is
sufficient to
authorize. One failed challenge fails the authorization/order.

> I was expecting something like '''a stub account object optionally
containing the
> "contact", "termsOfServiceAgreed", "onlyReturnExisting", and
> "externalAccountBinding" fields.'''

I understand now, thanks! Updated to say "and optionally the
"onlyReturnExisting" and "externalAccountBinding" fields". I think that will
cover this.

> If "termsOfService" is present in the directory, is the client required to
> agree to the terms before service is provided?  The text, to me, seems to
> allow a server to use this field to provide some optional additional
> documentation without requiring clients to agree to it.

I don't think the text suggests that. Section 7.3 "Account Creation" says:

> If the server wishes to present the client with terms under which the
> ACME service is to be used, it MUST indicate the URL where such terms
> can be accessed in the "termsOfService" subfield of the "meta" field
> in the directory object, and the server MUST reject new-account
> requests that do not have the "termsOfServiceAgreed" field set to
> "true".

So if termsOfService is present you MUST send termsOfServiceAgreed to be
able to
create an account. I don't think there is a reading of that text that would
allow the server to provide additional documentation without requiring
client
agreement.

> I think it would help to say '''MUST ignore any updates to [...], the
> "status" field (except as allowed by Section 7.3.7), or any other [...]'''

Good suggestion. Done.

> It seems that they would then be removed from the listing on page 46 (of
> the -14)?

I think the best fix here is to remove "valid" from "After a valid request
to
finalize has been issued". I've made this change.

> This would be § 4.4.2 of RFC 8446

Thanks. Added a ref to RFC 8446.

> Well now I'm really confused.  If I look at the example exchanges for the
HTTP challenge.

Apologies. I forgot that the HTTP-01 challenge type does send the token in
the
request by way of the request path.

I removed the language that says it "expresses a domain holder's
authorization".

> In particular, right now I think that the text about "participating in the
> creation" is inaccurate.

Rephrased to say that the entropy requirement only prevents guessing the
token
and removed text about "participating in the creation".

Thanks.


On Sun, Sep 16, 2018 at 6:29 PM Benjamin Kaduk <[e-mail]> wrote:

> On Sun, Sep 16, 2018 at 10:42:26PM +0200, Felix Fontein wrote:
> > Hi,
> >
> > > > > > > >    [...] Secondly, the entropy requirement
> > > > > > > >    prevents ACME clients from implementing a "naive"
> > > > > > > > validation server that automatically replies to challenges
> > > > > > > > without participating in the creation of the initial
> > > > > > > > authorization request.
> > > > > > > >
> > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP
> > > > > > > > mechanism -- couldn't you write a script to reply
> > > > > > > > to .well-known/acme-challenge/<foo> with <foo>.<key
> > > > > > > > thumbprint> for a fixed key thumbprint?  The validation
> > > > > > > > thumbprint> server would ned to
> > > > > > > > know about the ACME account in question, but not about any
> > > > > > > > individual authorization request.
> > > > > > >
> > > > > > > It would also need to know the <foo> value, which is not
> > > > > > > provided in the validation request specifically to avoid
> > > > > > > this.
> > > > > >
> > > > > > As I said above, "[w]ell now I'm really confused."  In the
> > > > > > example HTTP challenge exchange (duplicated here):
> > > > > >
> > > > > > GET
> /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0
> > > > > > Host: example.org
> > > > > >
> > > > > > HTTP/1.1 200 OK
> > > > > > Content-Type: application/octet-stream
> > > > > >
> > > > > >
> LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI
> > > > > >
> > > > > > Doesn't the path in the GET include the <foo>?
> > > > >
> > > > > Yes, and some people are already using this to add a generic
> > > > > authorization replier (which needs the thumbprint of the account
> > > > > key). For example, the acme.sh client supports this "stateless
> > > > > mode" (as it is called there):
> > > > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode
> > > >
> > > > Okay, that matches up with my understanding and maybe un-confuses
> > > > me.
> > > >
> > > > But does this state of affairs nullify the text in the -14 about:
> > > >
> > > >    [...] the entropy requirement
> > > >    prevents ACME clients from implementing a "naive" validation
> > > > server that automatically replies to challenges without
> > > > participating in the creation of the initial authorization request.
> > > >
> > > > ?
> > >
> > > Also, if we wanted to prevent this sort of dumb script, it seems like
> > > we could have the ACME server do a
> > > GET /.well-known/acme-challenge/<hash-of-token>
> > > instead of
> > > GET /.well-known/acme-challenge/<token>
> > >
> > > and expect the un-hashed token in the response body.  (Witih obvious
> > > questions about explicit hash agility vs. hardcoding a hash per
> > > challenge type.)
> >
> > That would work. However, I'm not sure whether this should really be
> > disallowed. I also understand the text from draft-14 as you do, but I
> > since this incorporates the account key hash, it doesn't validate for
> > challenges coming from other ACME accounts.
>
> Whether or not it should be disallowed is probably a function of the
> severity of the XSS risk (which I don't have a good picture of right now)
> -- as I attempted to note in my ballot text, the token is only created by
> virtue of the account key holder's explicit request, which could itself be
> seen as an authorizing action.  The echoing of the token by the HTTP server
> serves to confirm possession of the domain name, more than the specific
> authorization, in that worldview.
>
> > Also, there has been a proposal
> > (https://github.com/ietf-wg-acme/acme/issues/393) to allow something
> > similar for DNS validation (as dns-02), which explicitly mentions this
> > automation. Since nobody responded that such an automation is unwanted,
> > my assumption is that this automation is a feature and not a bug. It
> > would be nice if this would be more clear from the text, though.
>
> Agreed that the text could be more clear.  In particular, right now I think
> that the text about "participating in the creation" is inaccurate.
>
> -Benjamin
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>