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

[Alexey Melnikov <[e-mail]>]

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