Hi Ben,
I am sending you a partial reply, as I am still editing the document
based on some of your more detailed comments:
On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I have one point that I am not sure of the significance of and would
like to discuss further, and one point that I think has a fairly
clear/straightforward resolution.
One of the key properties of ACME is that its authenticator provides
assurance that both a party controlling the identifier to be certified
and the ACME client jointly assent to the certification request of that
identifier. I'm trying to explore a bit more the "jointly assent" part,
and whether it is clear that all steps of the challenge/validation flow
are ultimatetly tied to the same order request.
In the validation flows for the challenge types from 8555, the full
token is returned to the ACME client, which then provides the token to
the entity that controls the identifier being certified, in order to set
up state to expect a verification attempt using that token. In this
email validation flow, though, the token-part1 is *only* present in the
challenge email, so there is no thread of continuity that allows the
email account holder to tie the validation attempt to the specific
request (i.e., token). Any message that comes in claiming to be an ACME
challenge would end up being treated as a validation attempt for the
pending request, so the ACME server (or a party pretending to be one)
does not have to provide any proof of knowledge of the pending
validation before the response email is generated. Some key properties
here seem to include: there is a portion (token-part2) to the response
email that can only be provided by the ACME client, there is a part
(token-part1) to the response email that can only be provided by an
entity that can receive email at the email address being validated, and
that the validation attempt, response email, and ACME order request can
be tied together by unique identifiers. It seems that we could achieve
all three of these by having the HTTPS response to the ACME client
include a token-part0 as well as the token-part2, with token-part0 being
used as the subject line of the challenge email and token-part1 being
conveyed in some fashion (whether body or headers) of the challenge
email. Does such a scheme provide any useful properties that are not
provided by the current scheme?
We might need to have a conference call, as I don't fully understand
your concerns here. But let me think about this a bit more.
The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request. I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1. In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.
Yes. When I wrote this text I was thinking either user pushing a button
on a CA's website saying "initiate S/MIME certificate issuance for me",
running a command line tool a la Let's Encrypt or pushing a button in an
ACME-aware MUA. Can you suggest how to clarify this?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
The discuss point notwithstanding, if we assume that the current
validation process does provide the necessary linkage across steps, it
seems that the procedure would provide only similar properties to the
RFC 8555 validation flows -- I am having a hard time convincing myself
that we definitely have the 128-bit security level for all the
information paths at play. It seems like having both token-part1 and
token-part2 each be 128+ bits would be fairly low-cost and would give
greater peace of mind that we are not opening up any 64-bit attacks.
Making them both 128 bits is fine with me.
Using "ACME:" as the Subject: marker for both challenge mail and
response mail potentially sets us up for various reflection/janus-like
attacks.
Can you elaborate on this? Responses would have some kind of prefix in
front of "ACME" (e.g. "Re: ACME: ..."), so they will never be the same
subjects as in challenges.
We could give some warnings about this in the security
considerations, or just indicate in-band whether it is a challenge or a
response...
Section 3
contains at least 64 bits of entropy. (ACME server MUST generate
token afresh for each S/MIME issuance request.) The challenge
nit: missing article ("the"), twice ("The ACME server", "the token").
Already fixed in my copy due to other comments.
Best Regards,
Alexey
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
