Subject: Re: [secdir] Security review of draft-ietf-acme-email-smime-08

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Oct 2020 13:51:51 +0000

Hi Hilarie,

Thank you for your thorough review and sorry for the long delay in 
responding! My comments/questions below:

On 16/07/2020 19:04, Hilarie Orman wrote:
> 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.

My document can be extended/modified to apply to PGP/MIME, but I can't 
see anything else it would apply to. (Not covering PGP/MIME was a 
deliberate choice to keep the document simple.) So I would rather leave 
S/MIME 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)."
Thank you for the suggestion. Added.
> 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.

Yes. This require both ability to read emails, as well as being able to 
submit responses from the email address (which will imply being able to 
authenticate as the corresponding account owner to SMTP server).

> 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.
You are correct that this is not formally defined. An account owner is a 
user that authenticates to IMAP/POP & SMTP to read and respond to email. 
Do you think this should be formally defined in the document or maybe 
you can suggest a better term here?
> 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".
I admit I struggled a little bit with the verb to use here. "access" for 
me only implies ability to read, but not  necessary reply. E.g. POP or 
IMAP access. Can you think of a better verb here?
> 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
No, because certificate issuer doesn't send any email in the proposal. 
The certificate issuer and the ACME server might be the same entity, but 
this is already covered in the document.
> or requester's policy for DKIM/SPF/DMARC?
Good question. I had some commented out text requiring this in the 
document, but I was wondering whether this is too high of a bar to 
require. I will restore this text in the draft.
> 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.
Right. DNSSEC is not required, because requiring it would make this 
extension undeployable. Many domain owners just accept this risk when 
using email.
> 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.
I added some text, which hopefully clarifies this.
> 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.

Best Regards,

Alexey