Hi Alexey,
Part of what I include below is trying to summarize what we talked about on
our call earlier today; this will both help get our thoughts organized in a
semi-coherent fashion and let them get broader visibility.
On Thu, Nov 12, 2020 at 10:33:37AM +0000, Alexey Melnikov wrote:
> 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.
Yes. (In theory a user intermediating between a MUA and standalone ACME
client could also play this role, but it is hard to actually expect the
user to do so.)
On a related note, the thread with Fraser, combined with our live
discussion earlier today, made me realize that we really should say what
the contents of the 'url' field of the challenge object are. I know Fraser
wanted it to be an HTTPS resource, but it seems like a mailto: URL might
make more sense. A mailto: URL could also (in some cases) play the role of the
"token-part0" I had pondered about previously, in that if the ACME server
uses a challenge-specific address with sufficient entropy, and that is
the From: line of the challenge email, then a sufficiently aware MUA/client
can use that address to link the incoming challenge email with the pending
ACME challenge. (More below.)
> > 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.
As we discussed on our call, it's unusual to have information be both in
the Subject and body of the automated (challenge) email, so my initial
strawman doesn't look so great. It's also good to think about what risks
this mechanism would be protecting against -- it seems that, in the absence
of such a linkage mechanisms, the risk is that a MUA+client would
(potentially automatically) produce a response email in response to a
forged challenge email. The From: line of the forged message could, of
cousre, be forged, so this would be a potential backscatter vector, but I
don't think there would be much amplification per message, and probably the
client would only produce one response email and then try to poll the ACME
order, so there would only be one forgery possible per ACME request.
Furthermore, if the attacker causes the erroneous response email to go to
an attacker-controlled address, very little information is leaked -- we
send only the SHA256 hash of the key authorization, not the key
authorization itself, so no parts of the token or the the account key
thumbprint are leaked. In effect, the attacker has one chance to guess the
token-part1, and that's about it, and there's still the issue of the
account key thumbprint to consider as well.
Given this level of risk, just checking the challenge email's From address
against the challenge url may be a sufficient defense, even if the email
address in question does not contain much entropy.
> >>> 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.)
I am not confident that we can do so to any real degree of reliability.
> > 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.
That's a worthy goal.
Let's consider what the risks are if such an attack occurs. A legitimate
client can limit itself to sending only one response email per ACME
challenge, and can treat messages that look like replies as not being valid
challenge emails, so any given misdirected response email will produce at
most one additional/reflected response email from any given client.
Furthermore, a closed loop of self-sustaining reflections is not possible
because nobody is going to inadvertently strip the reply prefix, and any
given node will reject the reply prefix it adds. So perhaps a chain of a
few reflections might be possible if there are some clients that use
different reply-prefix tags and the To/From/Reply-To works out (which I
didn't even try to think through), but it will stop pretty fast.
Furthermore, there's not much information leakage from a reflected
response, since you can't learn a valid token-part1 with it (you'd have to
spoof the message that introduces the token-part1, and thus guess the
token-part1 at the same time), and the other body content (the PEM-like
ACME RESPONSE) is a SHA256 output that is also fairly hard to attack, with
a lot of its input being unpredictable. On the whole, these risks don't
seem to be terribly significant, so a countermeasure that only mostly works
may be good enough, which is basically what the reply-prefix tagging is
doing. I expect that MUAs can use reasonable heuristics for what is or
isn't a reply prefix and act accordingly.
So, in summary, we should add text recommending (or requiring?) that an
ACME client does add some kind of (nonempty) reply prefix to its response
subject line, that it treat messages containing that reply prefix before
"ACME:" as invalid challenges, ideally that it has stronger heuristics than
that about reply prefixes, and that it produce at most one response email
per ACME challenge.
Does that seem reasonable?
Thanks,
Ben
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
