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

[Benjamin Kaduk <[e-mail]>]

On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > 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.

This is fine.  It's kind of a shame that there isn't a more explicit field
in the registry, since there are lots of consumers that have to do this
sort of check (and exploits against some JWT libraries that failed to do
so...)

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

Okay, so as far as the spec is concerned they have global scope.
I asked because (on my first read) some of the text almost implied that the
server was tracking which clients it issued which nonces to.  I don't get
much of that sense on a reread, though; probably it was at the start of §
6.4 when the server is "maintaining a list of nonces that it has issued to
clients".  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.

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

I think my concerns in this space have been entirely subsumed by Adam's
DISCUSS, yes.

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

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

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.

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

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.

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

I guess my question was whether all listed contacts were presumed to be
"functionally equivalent" as far as the ACME server is concerned.  It
sounds like that's the case, and there may not be need to add any
clarifying text in the document.

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

I cannot (this was mostly an editorial question).  I think there has been
some discussion in a different branch of the thread, too, as well as in
https://github.com/ietf-wg-acme/acme/pull/447 .  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 -- the direction of the answer is not
something I have an opinion on.

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

I think https://github.com/ietf-wg-acme/acme/pull/447 will probably cover
this.

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

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

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

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.

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

(This is also rendered moot by Adam's DISCUSS.)

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

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

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

Sure.  I mostly assume that it is only needed for requests that actually
create an account, but if that's the case then the text would need to be
clarified.

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

Okay.

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

Okay.  I would like to avoid having needless normative requirements if
there is in fact no reason for this requirement.

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

Okay.

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

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

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

This would be § 4.4.2 of RFC 8446 ("The sender's certificate MUST come in
the first CertificateEntry in the list.  Each following certificate SHOULD
directly certify the one immediately preceding it.").

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

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

   GET /acme/authz/1234/0 HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "type": "http-01",
     "url": "https://example.com/acme/authz/0",
     "status": "pending",
     "token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0"
   }

and

GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0
Host: example.org

HTTP/1.1 200 OK
Content-Type: application/octet-stream

LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI

The token is returned in the response to the first GET (which I guess will now
be the GET-as-POST or POST-as-GET construct) and is part of the request URL
in the second GET.  The ACME server constructs the first response (and thus
the token), and the ACME server also already knows the client's key
thumbprint, so the the ACME server can construct the key authorization
string (and in fact, has to be able to do so in order to verify the
challenge!).  Thus, the ACME server can be in possession of the key
authorization immediately after generating the response to the "GET
/acme/authz/..." request.  It is very strained language to say that the
string itself expresses any authorization information in vacuum.  The
authorization that occurs is when it is presented at a specific place when
the ACME server goes to try to verify the challenge, which requires more
context than just the string itself.

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

Okay.

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

I had a mental picture of an "easy webserver deployment package" that
included a webserver that would make its own LetsEncrypt^WACME requests to
get a certificate for its configured domain(s) when it first starts up.
In such a case, the two boxes might be represented as sharing an edge.
(But of course they would not always be so tightly connected.)

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

I mean, I think we *are* implicitly placing requirements on all (HTTP|DNS)
server operators, namely, to avoid the "several ways that these assumptions
can be violated, both by misconfiguration and by attacks".  So the only
sort of text that I would consider adding in this document would be some
explanation of why it is okay for us to be placing such global requirements
on all servers, even ones that do not intend to use this protocol.  For
example, we might note that "the .well-known tree of URLs is by design
intended to be used for privileged configuration actions (among other
things), so it is irresponsible for a web server operator to construct
responses under .well-known that do not correspond to specific registered
values for standards that that web server intends to implement.  As such,
the ACME requirement that only the web server operator can write to
.well-known is reasonable to expect of a generic web server operator, even
one not implementing ACME."

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

Thanks!

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

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


> Thanks for your review.

Thanks for the updates!

-Benjamin

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