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

[Alexey Melnikov <[e-mail]>]

Hi Ben,

On 06/11/2020 22:29, Benjamin Kaduk wrote:
> Hi Alexey,
>
> On Thu, Nov 05, 2020 at 11:07:02AM +0000, Alexey Melnikov wrote:
>> Hi Ben,
>>
>> I am sending you a partial reply, as I am still editing the document
>> based on some of your more detailed comments:
> Sure, happy to handle things in batches.
>
>> 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.
> [We have scheduled a call, out of band.]
>
> Maybe I can try to step through the http case and the email case.
> I am sure I will miss some steps since the distinction between user, web
> server/email operator, ACME client, and possibly other entities, can be
> fuzzy at times.
>
> For HTTP, it's something like:
>
> 1) user wants a cert
> 2) user makes ACME client create a new order
> 3) ACME server creates the order+challenge, returning token to ACME client
> 4) user gets token from ACME client and provisions the webserver to handle
>    a challenge with that token
> 5) ACME server makes an HTTP validation query using the token value
> 6) webserver responds to challenge using key authorization
> 7) success
>
> Note that in (4) the webserver knows what token to expect, so the
> challenge/response are tightly tied to the particular order (because the
> token value is tied to the order).
>
> For email, it seems like we're proposing:
>
> 1) user wants a cert
> 2) user directs email client to direct ACME client to create a new order
> 3) ACME server creates the order+challenge, returns token-part2 to ACME
>    client
> 4) user directs email client or other infrastructure to expect a challenge
>    (including token-part2)
> 5) ACME server sends challenge email with token-part1
> 6) email client notes that an ACME challenge arrived, searches for
>    information about any pending expected challenges, and finds token-part2
> 7) user/email client produces challenge response including key
>    authorization (using token-part1 and token-part2)
Thank you for this. I agree that this level of details is definitely 
missing from the current draft and I will expand on the above in the 
next version of the draft.
> The part in (6) where the email client has to search for all/any pending
> expected challenges seems much weaker than in the HTTP case, as *any*
> incoming message formatted like an ACME challenge could elicit the response
> message.
As a side note: the above ("expecting challenges") is true for 
ACME-aware email client, but not for the case of unaware email client.
> This would not directly leak token-part2 (IIUC -- there would be
> a pretty straightforward copy/paste attack if we did!) since we hash the
> key authorization before transport, but it still seems problematic (and
> could, e.g., reveal that the client is expecting an incoming ACME
> challenge).  It seems "safer" in some intuitive sense if the email client
> knows exactly what challenge to expect and that is tied to a specific
> order.  The challenge does need to include some information that is not
> obtained in any other way, though, of course.
Ok. I am open to suggestions about what should be included in the ACME 
email challenge.
>>> 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?
> I am not sure how the "button on CA's website" would work -- you need a
> full ACME client with registered key/etc. in order for the ACME order flow
> to work.  I am pretty sure that the architecture assumes that the ACME
> client is associated with the entity receiving the cert (often, but not
> always, colocated), not with the CA.
For the button on the website case I was thinking about integrated web 
mail and hosted email. Think of Gmail or Fastmail case. The ACME client 
will be a part of the web mail client and will be preconfigured to talk 
to a specific ACME server.
> My current best thought is that we say up front that there is an ACME
> client involved in the issuance process, which could be integrated into a
> MUA, a local command-line command, etc.
Yes. I spent some time drawing diagrams for cases when ACME client is a 
part of MUA, as well as when ACME client is a stand alone command line 
tool or a web server. Luckily the workflow is pretty much the same in 
all these cases.
> Then the subsequent steps that
> involve that ACME client have more context.
>
>>> ----------------------------------------------------------------------
>>> 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.
> I guess I had not looked closely at this subtlety, but having done so, I am
> not convinced that we can really rely on the "ACME:" in the challenge being
> the start of the subject (nor do we imply that the client needs to be
> enforcing this attribute!).  Consider, for example, how many "[BULK]",
> "[EXTERNAL]", etc. tags are added in various environments.
Hmm, Ok. Can we describe generic structure of these exta tags in ABNF? 
(See why below.)
> So in practice,
> I expect "Subject: <arbitrary stuff> ACME: <token-part1>" to match as both
> a challenge and as a response.  I am not sure what cost there would be in a
> client changing it to use (e.g.) "ACME-RESPONSE:" in the response, and not
> having to worry about reflection or misbinding attacks seems like a
> significant benefit, so the cost/benefit analysis seems pretty clear to me
> so far :)
Using ACME-RESPONSE would work for ACME-aware email clients, but doesn't 
work if one just wants to continue using their Thunderbird or Outlook. 
(Because telling users that they need to paste something in a reply AND 
they have to modify the subject of replies is just too error prone). I 
still want the case of ACME-unaware email client to be supported.

Best Regards,

Alexey