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

[Benjamin Kaduk <[e-mail]>]

On Mon, Sep 24, 2018 at 11:54:42AM -0400, Daniel McCarney wrote:
> Here's another PR with further feedback:
> https://github.com/ietf-wg-acme/acme/pull/453
> 
> Replies in-line below.

Also in-line.

> > 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.

I was only suggesting it because this part felt like an introduction that
was enumerating an exhaustive list of usage of the "link" header field.
If that's not the intent, then my comment is not relevant and should be
ignored.

> > 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.

>From what I remember of it going by, I agree that it's clear now.

> > 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.

It should (though my understanding was that all four were optional, so
there would be no need to use the word "optionally" twice).

> > 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 read it as "if the server requires X, it does Y.  If the server doesn't
require X, we don't specify anything.", and security reviewers generally
try to avoid dangling edge cases.  Explicitly saying that "when the
termsOfService subfield is present, the client MUST indicate agreement
before service can be provided" (or similar) would resolve the alleged edge
case.

> > 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.

Ah, that sounds good -- thanks.

> > 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".

Sounds good; sorry for spending so much time on this point, which is in the
grand scheme of things quite minor.

> > 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!

-Benjamin

> 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
> >