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

[Daniel McCarney <[e-mail]>]

> My co-author Daniel McCarney is working on the COMMENT comments.

I've addressed most of the "COMMENT" feedback in the following PR:
  https://github.com/ietf-wg-acme/acme/pull/451

Further replies inline below. As a note, I'm a bit starved for time. Because
I don't have a usecase for account key binding and have not implemented it
I defer to others in the WG for comments related to section 7.3.5.

> It's probably worth going over the examples and checking whether nonce
> values are repeated in ways that are inconsistent with expected usage.
For
> example, I see these three values appearing multiple times (but I did not
> cross-check if a nonce returned in the Replay-Nonce response header was
> then used in a JWS header attribute):
>     2 K60BWPrMQG9SDxBDS_xtSw
>     3 IXVHDyxIRGcTE0VSblhPzw
>     4 JHb54aT_KTXBWQOzGYkt9A

Good idea. I did a pass to check for inconsistencies.

>   Different types of certificates reflect different kinds of CA
>   verification of information about the certificate subject.  "Domain
>   Validation" (DV) certificates are by far the most common type.  The
>   only validation the CA is required to perform in the DV issuance
>   process is to verify that the requester has effective control of the
>   domain.
>
> Can we get an (informative) ref for the "required"/requirements?

Done.

> W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link.

Thanks. Seems like we should use W3C.CR-cors-20140116 instead. Fixed.

> IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does
> not appear to include an explicit indicator of whether an algorithm is
> MAC-based; do we need to include text on how to make such a determination?

Unfortunate. I added text saying the "Alogrithm Description" should not
mention
MAC/HMAC. Please suggest alternative text if you don't like mine.

> For servers following the "SHOULD ... string equality check" and for
> requests where the equality check fails, does that fall into the "MUST
> reject the request as unauthorized" bucket?

Yes. Clarified.

>   In order to protect ACME resources from any possible replay attacks,
>   ACME requests have a mandatory anti-replay mechanism.
>
> We don't seem to actually define what an "ACME request" is that I can see.
> >From context, this requirement only applies to JWS POST bodies, and not
to,
> say, newNonce, but I wonder if some clarification would be useful.

Sure, fixed to "ACME POST requests have a ...".

>  IMPORTANT: How tightly are these nonces scoped?  Are they only good on a
> specific TLS connection?  Bound to an account key pair?  Globally valid?
> (This is not a DISCUSS point because AFAICT there is no loss in security
if
> the nonce space is global to the server.)

It should be left to the server to accept/reject and the client to retry as
described. I don't think the specification should prescribe the way
nonces are scoped by the server operator.

> IMPORTANT: Providing an accountDoesNotExist error type probably means we
> need to give guidance that the server should choose account URLs in a
> non-guessable way, to avoid account enumeration attacks.

I think this is covered in https://github.com/ietf-wg-acme/acme/pull/445

>    [...] Servers
>    MUST NOT use the ACME URN namespace Section 9.6 for errors other than
>    the standard types.
>
> "standard" as determined by inclusion in this document, or in the IANA
registry?

Alexey raised this as well and a fix is included in PR
https://github.com/ietf-wg-acme/acme/pull/442

> The "up" link relation for going from certificate to chain seems to only
be
> needed for alternate content types that can only represent a single
> certificate.  (Also, the "alternate" link relation is used to provide
> alternate certifciation chains.)  Could this text be made more clear?

I'm not sure I understand the part that isn't clear. Do you have a suggested
edit?

> Presumably this is just my confusion, but what does "GET order
certificate"
mean?

It means sending a GET request to the URL found in the Certificate field of
a
valid status Order resource.

>   [...] It is a JSON
>    object, whose field names are drawn from the following table and
>    whose values are the corresponding URLs.
>
> Er, from the IANA registry, right?

Fixed.

>  The following metadata items are defined, all of which are OPTIONAL:
> Maybe also refer to the registry?

Fixed.

> IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a
> human" thing or not.  If there are supposed to be different URLs that are
> used for different purposes, wouldn't more metadata be needed about them?
> So it seems most likely that this is indeed "talk to a human", in which
> case that might be worth mentioning.  (Are these always going to be
> mailto:?)

The text says the contact is for "contacting the client for issues related
to
this account". I don't think it matters whether it be for talking to a
human or
not. They are not always going to be mailto:, that is clarified in 7.3
"account
creation"

> IMPORTANT: Am I reading this correctly that the GET to the orders URL does
> not require the client to be authenticated, in effect relying on
> security-through-obscurity (of the account URL) for indicating which
> account is trying to order certificates for which identifiers?

See https://github.com/ietf-wg-acme/acme/pull/445

>   challenges (required, array of objects):  For pending authorizations,
>      the challenges that the client can fulfill in order to prove
>      possession of the identifier.  For final authorizations (in the
>      "valid" or "invalid" state), the challenges that were used.  Each
>      array entry is an object with parameters required to validate the
>      challenge.  A client should attempt to fulfill one of these
>      challenges, and a server should consider any one of the challenges
>      sufficient to make the authorization valid.
>
> This leaves me slightly confused.  A final authorization can have multiple
> challenges.  But a client should only attempt to fulfill one, and a server
> should treat any one as sufficient.  So I can only get to the case with
> multiple challenges present in a final order of both "should"s are
> violated?

I don't understand - can you expand on this with a concrete example
of requests/responses?

> Is there a way for the server to express that multiple challenges are
going
> to be required?

No.

> Hmm, but Section 7.1.6's flow chart for Authorization objects says that a
> single challenge's transition to valid also makes the authorization
> transition to valid, which would seem to close the window?
> Section 7.5.1 has inline text that implicitly assumes that only one
> challenge will be completed/validated.

Yes. That's the intention. Clarification suggestions welcome.

>   wildcard (optional, boolean):  For authorizations created as a result
>      of a newOrder request containing a DNS identifier with a value
>      that contained a wildcard prefix this field MUST be present, and
>      true.
>
> Is there a difference between false and absent?

No.

>    A client creates a new account with the server by sending a POST
>    request to the server's new-account URL.  The body of the request is
>    a stub account object optionally containing the "contact" and
>    "termsOfServiceAgreed" fields.
>
> Given that we go on to describe those two and also the optional
> onlyReturnExisting and externalAccountBinding fields, does this list need
> expanding?

What do you think is missing?

> IMPORTANT: How does the client know if a termsOfService in the directory
is
> actually required or just optional?  (There doesn't seem to be a dedicated
> error type for this?)  The text as-is seems to only say that if the server
> requires it, the field must be present in the directory, but not the other
> way around.  I guess Section 7.3.4 describes the procedure for a similar
> case; should the same thing happen for the original terms acceptance?

I'm not sure I understand. The text as-is in 7.3 and 7.3.4 seem clear to
me.
Are you asking what happens if the server doesn't require a terms of
service?

> IMPORTANT: The example response uses what appears to be a sequential
> counter for account ID in the returned account URL, which loses any sort
of
> security-through-obscurity protections if those were desired.  Should a
> more opaque URL component be present, maybe a UUID?  (The "orders" field
> would need to be modified accordingly, of course, and this pattern appears
>in later examples, as well.)

There is no security-through-obscurity desired here. Knowing the account URL
doesn't give you any information unless you also control the account's
associated keypair to be able to POST the resource.

> It's a little unclear to me whether the fields the client can put in the
> POST are the ones listed from Section 7.3 or 7.1.2, or the full set from
> the registry.  But presumably the server must ignore the "status" field,
> too, or at least some values should be disallowed!  The IANA registry's
> "configurable" column may not quite be the right thing for this usage,
> especially given how account deactivation works.

The status field should not be ignored because this is how account
deactivation
is performed. You are correct that some status values need to be ignored
(anything other than "deactivated"). (Section 7.3.7)

Do you think further clarification is required? If so please suggest text.

>> The server MAY require a value for the "externalAccountBinding" field
>> to be present in "newAccount" requests.
>
> All requests including queries for the current status and modification of
> existing accounts?  Or just creation of new ones?

I defer on this to the other authors/people that want
externalAccountBinding to
be a thing.

>> To enable ACME account binding, the CA operating the ACME server
>> needs to provide the ACME client with a MAC key and a key identifier,
>> using some mechanism outside of ACME.
>
> This key needs to also be tied to the external account in question, right?
> One might even say that it is provided not to the ACME client, but to the
> external account holder, who is also running an ACME client.

I defer on this to the other authors/people that want
externalAccountBinding to
be a thing.

>> [...] The payload of this JWS is the account key being registered, in
JWK form.
>>      this JWS is the account key being registered, in JWK form.
> This is presumably my fault and not the document's, but I had to read this
> a few time to bind it as the ACME account key, and not the external MAC
> key.

Fixed.

>> If a CA requires that new-account requests contain an
>> "externalAccountBinding" field, then it MUST provide the value "true"
>> in the "externalAccountRequired" subfield of the "meta" field in the
>> directory object.  If the CA receives a new-account request without [...]
> nit: maybe "If such a CA"?

Fixed.

> IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in
> the external-binding JWS object, though I think I understand why one is
not
> needed in order to bind the MAC to the current transaction.  (That is,
this
> is in effect a "triply nested" construct, where a standalone MAC that
> certifies an ACME account (public) key as being authorized by the
> external-account holder to act on behal of that external account.  But
this
> standalone MAC will only be accepted by the ACME server in the context of
> the outer JWS POST, that must be signed by the ACME account key, which is
> assumed to be kept secure by the ACME client, ensuring that both
> key-holding entities agree to the account linkage.)  Proof of freshness of
> the commitment from the external account holder to authorize the ACME
> account key would only be needed if there was a scenario where the
external
> account holder would revoke that association, which does not seem to be a
> workflow supported by this document.  Any need to effectuate such a
> revocation seems like it would involve issuing a new MAC key for the
> external account (and invalidating the old one), and revoking/deactivating
> the ACME account, which is a somewhat heavy hammer but perhaps reasonable
> for such a scenario.
> Account key rollover just says that the nonce is NOT REQUIRED, and also
> uses some nicer (to me) language about "outer JWS" and "inner JWS".  It
> might be nice to synchronize these two sections.

I defer on this to the other authors/people that want
externalAccountBinding to
be a thing.

> IMPORTANT: The "url" in this example looks like an account URL, not an
> account-deactivation url.  If they are one and the same, please include
> some body text to this effect as is done for account update in Section
> 7.3.2.

They are the same. Fixed.

> Is Section 7.1.3 or the registry a better reference for the request
> payload's fields?

I think 7.1.3 is a better reference.

> Does the exact-match policy (e.g., on notBefore and notAfter) result in CA
> maximum lifetime policies needing to be hardcoded in client software (as
> opposed to being discoverable at runtime)?

Only if clients decide to include the values in their request. There are
many
aspects of CA policy that are not exposed through ACME and the protocol
doesn't try to make that policy discoverable at runtime.

> IMPORTANT: Why does the example response include an identifier of
> www.example.com that was not in the request?

Fixed.

> Is the "order's requested identifiers appear in commonName or
> subjectAltName" requirement an exclusive or?

It is not an exclusive or.

> After a valid request to finalize has been issued, are "pending" or
"ready"
> still valid statuses that could be returned for that order?

No.

> Elsewhere when we list "identifier (required, object)" in a JWS payload we
> also inline the "type" and "value" breakdown of the object.

Fixed to be consistent.

> How is "expires" set for this pre-authorization object?

Server decides it based on its own policies.

> We probably need a reference for "certificate chain as defined in TLS".

Sounds reasonable, can you suggest a reference?

> "When a client receives an order from the server" is a bit jarring without
> some additional context of "in a reply to a new-order request" or "an
order
> object" or similar.

Fixed.

>   To do this, the client updates the authorization object received from
>   the server by filling in any required information in the elements of
>   the "challenges" dictionary.
>
> "challenges" looks like an array of objects, not directly a dictionary
with
> elements within it.

Good catch. This is a leftover. Fixed.

> IMPORTANT: What do I do if I get a challenge object that has status
"valid"
> but also includes an "error" field?

I clarified an error value MUST mean the status is invalid.

>   [...] A key authorization is a string that expresses
>   a domain holder's authorization for a specified key to satisfy a
>   specified challenge, [...]
>
> I'm going to quibble with the language here and say that the
> keyAuthorization string as defined does not express a specific
> authorization for a specific challenge, since there is no signature
> involved, and the JWK thumbprint is separable and can be attached to some
> other token.  (This may just be an editorial matter with no broader
impact,
> depending on how it's used.)  One could perhaps argue that the mere
> existence of the token constitutes an authorization for a specified key to
> satisfy the challenge, since the token only gets generated upon receipt of
> such an authorized request.

It expresses authorization for a specific challenge by way of including the
token value from that challenge. The token is not communicated in the
challenge
request.

> I'm not sure that 4086 is a great cite, here.  For example, in RFC 8446 we
> say that "TLS requires a [CSPRNG].  In most case, the operating system
> provides an appropriate facility [...] Should these prove unsatisfactory,
> [RFC4086] provides guidance on the generation of random values."  On the
> other hand, citing 4086 like this is not wrong, so use your judgment.

Without an alternative suggestion it seems like the best choice.

>   4.  Verify that the body of the response is well-formed key
>       authorization.  The server SHOULD ignore whitespace characters at
>       the end of the body.
>
> nit: "a well-formed"

Fixed.

> Can we get some justification for the "SHOULD follow redirects", given the
> security considerations surrounding doing so?

There is a forward reference to security considerations now. Following
redirects is normal HTTP semantics.

> Should this "token" description include the same text about entropy as for
> the HTTP challenge?

Fixed.

> There is perhaps some subtlety here, in that the "configurable" column
> applies only to the new-account request, but its description in the
> template does not reflect that restriction.  In particular, "status"
values
> from the client *are* accepted when posted to the account URL, e.g., for
> account deactivation.

We should try to clarify this. I'll submit a separate PR.

> Can there be overlap between the "validation server" function and the
"ACME
> client" function?

I can't think of a scenario where this would be true.

>    [...] The key authorization reflects the
>   account public key, is provided to the server in the validation
>   response over the validation channel and signed afterwards by the
>   corresponding private key in the challenge response over the ACME
>   channel.
>
> I'm stumbling up around the comma trying to parse this sentence.  (Maybe a
> serial comma or using "and is signed" would help?)
> IMPORTANT: Also, I don't see where the key authorization is signed in the
> challenge response -- the payload is just an empty object for both the
HTTP
> and DNS challenges' responses.

The reference to the keyAuthorization being sent in the signed payload in a
POST to a challenge should be removed as its a leftover. Fixed.

> Some of this text sounds like we're implicitly placing requirements on all
> (HTTP|DNS) server operators (not just ones trying to use ACME) to mitgate
> the risks being described.  In general this sort of behavior seems like an
> anti-design-pattern, though perhaps one could argue that the behaviors in
> question should be avoided in general, indepnedent of ACME.

I don't understand how you got this impression from the text. Can you
suggest
changes?

>   Some server implementations include information from the validation
>   server's response (in order to facilitate debugging).  Such
>
> Disambiguating "ACME server implementations" may help, since we talk about
other HTTP requests in the previous paragraph.

Fixed.

> IMPORTANT: This may be an appropriate place to recommend against reuse of
> account keys, whether after an account gets deactivated or by cycling
> through keys in a sequence of key-change operations (or otherwise).  I
> think there are some attack scenarios possible wherein (inner) JWS objects
> could be replayed against a different account, if such key reuse occurs.

Seems reasonable to discuss account key reuse here. Added a new MUST.

>   The http-01, and dns-01 validation methods mandate the usage of a
>
> nit: spurious comma.

Fixed.

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

Thanks for your review.


On Wed, Aug 29, 2018 at 9:10 PM, Richard Barnes <[e-mail]> wrote:

> Hi Ben,
>
> Thanks for the detailed review.  Responses to the DISCUSS comments
> inline.  My co-author Daniel McCarney is working on the COMMENT comments.
>
> --Richard
>
> On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk <[e-mail]> wrote:
>
>>
>> It looks like the server returns an unauthenticated
>> "badSignatureAlgorithm"
>> error when the client sends a JWS using an unsupported signature algorithm
>> (Section 6.2).  What prevents an active attacker from performing a
>> downgrade attack on the signature algorithm used?
>>
>
> HTTPS, and the minimum requirements established in this document.  We can
> add some comments to the Security Considerations if you want.
>
>
>
>> Similarly, since we include in the threat model a potentially hostile
>> CDN/MitM between the ACME client and ACME server, can that attacker strip
>> a
>> success response and replace it with a badNonce error, causing the client
>> to retry (and thus duplicate the request processing on the server)?
>>
>
> In the spectrum of DoS attacks the CDN could wage against the server, this
> seems pretty lame.  The CDN could also just stop forwarding requests.
>
> In other words, I don't really think the
>
>
>> I am not an ART AD, but there is not yet an internationalization
>> directorate, and seeing statements like "inputs for digest computations
>> MUST be encoded using the UTF-8 character set" (Section 5) without
>> additional discussion of normalization and/or what the canonical form for
>> the digest input is makes me nervous.  Has sufficient internationalization
>> review been performed to ensure that there are no latent issues in this
>> space?
>>
>
> Two of the three ART ADs have already signed off, so we have that going
> for us :)
>
> The only place we have human-readable text is in the problem documents, so
> at that level, the i18n considerations are handled by that spec.  Other
> than that, everything is ASCII, so saying "UTF-8" is just a fancy way of
> saying, "don't send extra zero bytes".
>
>
>
>> Section 6.1 has text discussing TLS 1.3's 0-RTT mode.  If this text is
>> intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data
>> for the ACME protocol, I think you need to be more specific and say
>> something like "MAY allow clients to send early data (0-RTT); there are no
>> ACME-specific restrictions on which types of requests are permitted in
>> 0-RTT", since the runtime configuration is just 0-RTT yes/no, and the
>> protocol spec is in charge of saying which PDUs are allowed or not.
>>
>
> The risk for HTTPS with 0-RTT is replay of requests.  The text already
> notes that that is not an issue for ACME requests because they have their
> own anti-replay protection.  There are no restrictions on which PDUs are
> allowed.   What further specificity do you need?
>
>
>
>> Section 6.2 notes that servers MUST NOT respond to GET requests for
>> sensitvie resources.  Why are account resources the only sensitive ones?
>> Are authorizations not sensitive?  Or are those considered to fall under
>> the umbrella of "account resources" (Section 7.1 seems pretty clear that
>> they do not)?
>>
>
> That sentence has an overly prescriptive tone.  Obviously it's up to the
> CA's policy what it considers sensitive.  (Some especially profligate CA
> that's not subject to GDPR might be OK publishing its account objects.)
> Happy to dial it back to something like "For example, most CAs will likely
> consider account resources to be sensitive."
>
>
>
>> Section 7.1.1 discusses how the server can include a caaIdentities element
>> in its directory metadata; does this (or anything else) need to be
>> integrity protected by anything stronger than the Web PKI cert
>> authenticating the HTTPS connection?  It seems that a bogus caaIdentities
>> value could lead to an unfortunate DoS in some cases.
>>
>
> I don't know what you would consider stronger than a WebPKI cert.  You
> could use a secondary key that isn't provided to the CDN and do JWS in the
> server-to-client direction.  But that would require clients to configure a
> public key as well as a URL, and you would have to figure out whether you
> wanted caching or anti-replay and build the corresponding addenda to JWS.
> All in all, a lot of complexity for marginal benefit, especially this late
> in the game.
>
>
>
>> I am also a bit uncertain if the document is internally consistent about
>> whether one challenge verification suffices or there can be cases when
>> multiple challenge verifications are required for a successful
>> authorization.  I attmpted to note relevant snippets of the text in my
>> comments on Section 7.1.4.
>>
>
> The document is clear that (1) any one challenge is sufficient for a given
> authorization ("the server should consider any one of the challenges
> sufficient to make the authorization valid") and (2) the server may provide
> multiple authorizations in the order object if it requires multiple
> different validations.
>