Subject: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt

From: [email-masked]
Date: Sat, 01 Sep 2018 04:13:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment WG of the IETF.

        Title           : Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
        Author          : Alexey Melnikov
	Filename        : draft-ietf-acme-email-smime-03.txt
	Pages           : 7
	Date            : 2018-09-01

Abstract:
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-03
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 1 Sep 2018 16:22:04 +0100

> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-03

This version has a bit more meat in it, in particular I've added example
email challenge and response messages that are used to validate owneship
of an email address. I am sure that some details will change over time,
but this is a start.

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Tue, 04 Sep 2018 14:36:46 +0200

Hi Alexey,

thanks for working on the "email-reply-00" challenge. I would very much 
welcome a good mechanism to automatically distribute certificates for use with 
S/MIME.

I have two questions / suggestions to your proposal:

3.2.  ACME response email
-------------------------

You suggest to send the challenge response via email. What is the reason for 
choosing email as medium for this?

SMTP does allow choosing an arbitrary "From:" address, so just being able to 
send an email with a specific "From:" address alone doesn't prove anything.

But sending an email does require specific setup on the client side (like smtp 
relay server, port, login,...) which makes it harder to use an ACME client 
program that is not fully integrated into an email program.

Couldn't the token just be transmitted back to the CA via HTTPS like the rest 
of the ACME protocol?

Challenge email and mail filtering
-------------------------

If "email-reply-00" becomes popular (I'm hoping it will), it will most 
probably attract scammers which will try to trick users into giving away 
passwords and so on. As the challenge email mostly contains a random token, it
is not easy for mail filtering gateways to filter out scam emails and let 
legitimate challenge emails through. I think we should design the protocol in 
a way that makes it easy for mail filtering gateways to do the right
thing:

1. Every CA should publish (on their webpage or in a specification document) a 
static "From:" address they use when sending their challenges. This could be 
used by gateways for whitelisting purposes.

2. As simple whitelisting without further checks isn't a good idea, the 
authenticity of the challenge email should be verifiable by the filtering 
gateway. 

I propose that the CA should sign all challenge emails with S/MIME to do this. 
As most email programs already automatically check S/MIME signatures, this 
would also allow users of manual acme client programs to verify the 
authenticity of the challenge email.

What do you think?

Kind regards,

Gerd

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Tue, 04 Sep 2018 14:59:07 +0200

I think SPF / DKIM is more of a suitable method of verifying authenticity
for mails, since these can be verifyed automatically by most email server
software without any plugins.
Ergo, a CA **MUST** support SPF as validation method, both for sending and
receiving, and a ~ MUST be treated same as -, ergo hardfail. (Unknown should
however be treated same as non-existant record and then it should fallback
on DKIM and then SMIME)
And a CA **MAY** also support DKIM and/or SMIME as validation method both
for sending and receiving.

This solves both 3.2 and challenge emails. If the CA validate
SPF/DKIM/SMIME, you can't forge the From: adress.
You could also have that the CA sends a challenge email to the email in
question, but this requires rate limiting both on user @ domain.tld part,
and also per domain (* @ domain.tld) to prevent becoming a spam problem.

For gateway filtering, I suggest that a couple of static adresses is
reserved for this purpose:
acme @ [ca_domain_name].[tld]
abuse @ [ca_domain_name].[tld]
postmaster @ [ca_domain_name].[tld]

This allows gateway filters to automatically support any CA without any
extra configuration required on the administrator's end.

-----Ursprungligt meddelande-----
Från: Acme <[email-masked]> För Gerd v. Egidy
Skickat: den 4 september 2018 14:46
Till: [email-masked]; Alexey Melnikov <[email-masked]>
Ämne: Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt

Hi Alexey,

thanks for working on the "email-reply-00" challenge. I would very much 
welcome a good mechanism to automatically distribute certificates for use
with 
S/MIME.

3.2.  ACME response email

But sending an email does require specific setup on the client side (like
smtp 
relay server, port, login,...) which makes it harder to use an ACME client 
program that is not fully integrated into an email program.

Couldn't the token just be transmitted back to the CA via HTTPS like the
rest 
of the ACME protocol?

If "email-reply-00" becomes popular (I'm hoping it will), it will most 
probably attract scammers which will try to trick users into giving away 
passwords and so on. As the challenge email mostly contains a random token,
it
is not easy for mail filtering gateways to filter out scam emails and let 
legitimate challenge emails through. I think we should design the protocol
in 
a way that makes it easy for mail filtering gateways to do the right
thing:

1. Every CA should publish (on their webpage or in a specification document)
a 
static "From:" address they use when sending their challenges. This could be

I propose that the CA should sign all challenge emails with S/MIME to do
this. 
As most email programs already automatically check S/MIME signatures, this 
would also allow users of manual acme client programs to verify the 
authenticity of the challenge email.

What do you think?

Kind regards,

Gerd

_______________________________________________
Acme mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/acme

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Tue, 04 Sep 2018 15:28:13 +0200

Hi Sebastian,

> software without any plugins.

For servers yes, but for email clients the opposite is true. Most clients 
already automatically verify S/MIME. DKIM could be done in the client but SPF 
is particularly hard to do in a client.

> Ergo, a CA **MUST** support SPF as validation method
[...]
> And a CA **MAY** also support DKIM

Why this strong preference for SPF over DKIM? 

SPF isn't compatible with regular email forwarding and thus creates a lot of 
problems. See for example https://blog.fastmail.com/2016/12/24/spf-dkim-dmarc/ 
for details. I recommend my customers to only use DKIM and not use SPF at all 
because of this.

> and/or SMIME as validation method both
> for sending

I think the main point here is if we want to force clients to support full 
MIME decoding including S/MIME or not. Making this decision a MAY isn't good 
practice, as an ACME client without a full MIME parser will just stop to work 
once the CA decides to activate S/MIME. Also mail filtering gateways then 
can't rely on the kind of signing a CA does on the challenge mails.

> acme @ [ca_domain_name].[tld]

yes, good idea.

Kind regards,

Gerd

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 4 Sep 2018 15:06:46 +0100

Hi Gerd,

Thank you for your comments!

> I have two questions / suggestions to your proposal:

Because we need some way to prove control over the email address. This 
means both being able to read emails addressed to it and also being able 
to send on behalf of the email address.

> send an email with a specific "From:" address alone doesn't prove anything.
This is true, the document needs to add some text about some form of 
validation. Possibly DKIM/DMARC. I am still thinking about this, so 
maybe better mechanisms are available.
> Couldn't the token just be transmitted back to the CA via HTTPS like the rest
As per above, I think this is not good enough.
> Challenge email and mail filtering

DKIM/DMARC already deal with some of this, so I think they should be 
encouraged in this context. (They are easy to handle in MTAs, as more 
support is available).

Supporting S/MIME might be a reasonable alternative as well.

> What do you think?

I am a bit torn between requiring one, the other or even allowing both. 
More feedback from the WG would be useful.

Best Regards,

Alexey

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Tue, 04 Sep 2018 17:16:39 +0200

Hi Alexey,

> > SMTP does allow choosing an arbitrary "From:" address, so just being able
> > to send an email with a specific "From:" address alone doesn't prove
> > anything.
> validation. Possibly DKIM/DMARC.

fair enough.

> > rest of the ACME protocol?
> 

But wouldn't that create two different levels of validation?

Let's consider user Alice. She, or her domain admin, has set up DNSSEC, DKIM, 
SPF and DMARC. When she does the email-reply-00 challenge, mail reception and 
sending is proven properly.

But user Bob has none of that, just a basic domain with one A record, no 
DNSSEC and nothing else. When he does the email-reply-00 challenge, 
essentially just mail reception is proven, as sending could be forged without 
issue.

The CA would hand out the same kind of certificates to both of them and a 
third party won't know which level of validation was done. Querying the dns 
data of Bob won't help, because he could have changed it after the certificate 
was issued.

Is a CA like Let's Encrypt ok with such a difference?

Or do you want to make the use of DKIM and DMARC mandatory for a user before 
he can use the email-reply-00 challenge?

> Supporting S/MIME might be a reasonable alternative as well.

I'm ok with both of these mechanisms, they would both solve the issue.

I just think if we allow a CA to send S/MIME, there should be something like 
"a client MUST support decoding MIME emails" in the RFC so that there is no 
surprise if a CA suddenly starts using it.

Kind regards,

Gerd

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 6 Sep 2018 16:07:48 +0100

> data of Bob won't help, because he could have changed it after the certificate
I think it is CA's policy whether they want to trust an email address 
from a domain with no DMARC/DKIM/SPF/etc. But I think the document 
should specify whether there are any minimum requirements on email 
address validation.
> he can use the email-reply-00 challenge?
I am leaning this way. Or at least thinking of saying something like "or 
comparable validation" in the document.
> surprise if a CA suddenly starts using it.

I agree!

Best Regards,

Alexey