Last Call Review of draft-ietf-acme-email-smime-08
review-ietf-acme-email-smime-08-secdir-lc-orman-2020-07-16-00

Security review of 
Extensions to Automatic Certificate Management Environment for end user
S/MIME certificates
draft-ietf-acme-email-smime-08

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

The abstract states:
  "This document specifies identifiers and challenges required to enable
  the Automated Certificate Management Environment (ACME) to issue
  certificates for use by email users that want to use S/MIME."

I would restate this as "a specification of a challenge/response
protocol that is part of issuing ACME certificates to email accounts."

There doesn't seem to be anything in particular that ties this
document to S/MIME.  It would certainly be useful for using S/MIME,
but it is not necessary to have it in the title.

The protocol under discussion is a small part of ACME, and it appears
to be what results immediately from a request for a certificate.  In
section 3, last paragraph, there is a brief allusion to this context,
in the mention of the email address in a "CSR".  This would be
usefully augmented by using the text as in ACME, i.e., "a PKCS#10
[RFC2986] Certificate Signing Request (CSR)."

There's an assumption that the ability to reply to a challenge email from
the certificate server demonstrates "control" of the email account,
and therefore the possession of the private key for the certificate
demonstrates to a third party the "control" of the email account.  

The security considerations note that the requester's email system
might not be secure, and that email accounts might be shared, but
there is reference to the "account owner".  I don't think that there
is a formal notion of an account owner for email, perhaps it shouldn't
be mentioned.  The protocol demonstrates that an entity can see email
sent to the email address and can respond from that email address.
That is not necessarily "control", so I would replace that term with
something more neutral, like "access".

The challenge message must be protected with S/MIME signing or DKIM
signing, and pass DMARC validation.  The response message must be DKIM
signed.  Are there any requirements on the the certificate issuer's or
requester's policy for DKIM/SPF/DMARC?

This layering of security mechanisms raises the question of what do
they accomplish?  The document recommends that email system
administrators use DNSSEC to protect records that protect email, but
it isn't required.  Under what circumstances should the email user
feel confident in the issued certificate?  If it is used with S/MIME,
how much confidence should the recipient have in the certificate?  The
answer depends on a lot of factors in the details of DNS and email
infrastructure for the certificate issuer and the certificate
requester.

The ACME specification has a detailed discussion of security.  By
introducing email into protocol, this extension seems to raise new
security considerations that should be addressed in similar detail.


Hilarie