Subject: Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

From: Alexey Melnikov <[email-masked]>
Date: Sat, 2 May 2020 13:35:43 +0100

Hi Ben,

On 21/04/2020 01:12, Ben Schwartz wrote:
>
> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Ben,
>
>     My apologies for missing your email in March:
>
>
> And mine for this delayed response.
>
>     On 12/03/2020 20:42, Ben Schwartz wrote:
>>     Section 3 says token-part1 "contains at least 64 bit of entropy",
>>     but Section 3.1 says token-part1 "MUST be at least 64 octet long
>>     after decoding".  Is this difference deliberate?
>
>     No, I obviously made a typo when saying octets. I will fix.
>
Fixed.
>
>>     Also 64 octets of entropy is a _lot_.  RFC 8555 says "the token
>>     is required to contain at least 128 bits of entropy".
>>
>>     The draft seems to be oriented entirely toward use with e-mail
>>     clients that have a built-in ACME-S/MIME client.  I'm a bit
>>     disappointed that the draft doesn't accommodate users with
>>     "naive" email clients very well, e.g. by allowing customized
>>     subject lines.
>
>     Actually, I was trying to accommodate naive email clients, but it
>     was a fine balance trying to specify minimal requirements.
>
>     Can you suggest some specific text to change and then we can
>     discuss whether or not it should be done? My thinking about the
>     Subject header field was that I wanted to have a unique subject
>     (so that ACME email messages are easily findable). I also wanted
>     to allow the token in the subject for APIs that can easily access
>     Subject and not other header fields.
>
> In that case, I would suggest "... subject ending with "(ACME:
> <token-part1>)", where ...".  That would allow the first part of the
> subject (most likely to be seen by a human) to be human-readable.

After thinking a bit more about this:

As ACME servers are generating ACME challenge emails, the requirement on
them is stricter (they create the first message in an email thread). I
am tempted to leave this as is. Can you think of a case where ACME
servers would be unable to comply with this restriction?

ACME responses already allow arbitrary prefix to accommodate naive clients.

> Similarly, for Section 3.2. Point 6, I would relax the requirement to
> state that this block must appear somewhere in the body.  That way, if
> the user sees the response message, it can provide some explanation of
> what is going on.
Good idea. Changed.
> For Section 3.1 Point 5, I don't understand why the body is restricted
> to text/plain.  In particular, I think hyperlinks to explanations and
> instructions are likely to be helpful.  I also wonder whether support
> for multipart/multilingual could be useful.
> The body is irrelevant to ACME-aware clients, so it seems like there
> could be a lot of freedom in how this is constructed.

This is true for the challenge email.

There is a requirement on S/MIME (if used) to provide header protection,
but I agree that otherwise the body structure can be pretty flexible.

> Most email clients automatically convert HTTPS URLs to hyperlinks,
> which should make the silly schemes I'm imagining possible, but not
> very attractive, for ordinary users.
>
>     Best Regards,
>
>     Alexey
>
>>     I assume this is deliberate, perhaps because of a desire to use
>>     short-TTL S/MIME certificates that would be impractical to
>>     provision manually, but the draft doesn't mention a rationale.
>>
>>     On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich
>>     <rsalz=[email-masked]
>>     <mailto:40akamai.com@dmarc..ietf.org>> wrote:
>>
>>         This mail begins a one-week working group last call on
>>         https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1
>>
>>          
>>
>>         If you have comments or issues, please post here.
>>
>>          
>>
>>         If anyone wants to be a document shepherd, please contact the
>>         chairs.
>>
Best Regards,

Alexey

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 2 May 2020 14:11:02 -0400

On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov <[email-masked]>
wrote:

> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov <[email-masked]>
> wrote:
>
>> Hi Ben,
>>
>> Section 3 says token-part1 "contains at least 64 bit of entropy", but
>> Section 3.1 says token-part1 "MUST be at least 64 octet long after
>> decoding".  Is this difference deliberate?
>>
> Also 64 octets of entropy is a _lot_.  RFC 8555 says "the token is
>> required to contain at least 128 bits of entropy".
>>
>> The draft seems to be oriented entirely toward use with e-mail clients
>> that have a built-in ACME-S/MIME client.  I'm a bit disappointed that the
>> draft doesn't accommodate users with "naive" email clients very well, e.g.
>> by allowing customized subject lines.
>>
>> Actually, I was trying to accommodate naive email clients, but it was a
>> fine balance trying to specify minimal requirements.
>>
>> Can you suggest some specific text to change and then we can discuss
>> whether or not it should be done? My thinking about the Subject header
>> field was that I wanted to have a unique subject (so that ACME email
>> messages are easily findable). I also wanted to allow the token in the
>> subject for APIs that can easily access Subject and not other header fields.
>>
> them is stricter (they create the first message in an email thread). I am
> tempted to leave this as is. Can you think of a case where ACME servers
> would be unable to comply with this restriction?
>
My concern is that users will not know what to do if they receive an email
whose subject line is "ACME: awlkNSdpijawrfz...".  Users are used to seeing
emails whose subject line is "Please verify your email address" or "Confirm
your email".  (My inbox is full of them.)  I see no reason to disallow that
here.

Mandating that the subject line be non-human-readable seems like an
unnecessary barrier to adoption.

> state that this block must appear somewhere in the body.  That way, if the
> user sees the response message, it can provide some explanation of what is
> going on.
>
> Good idea. Changed.
>
> For Section 3.1 Point 5, I don't understand why the body is restricted to
> text/plain.  In particular, I think hyperlinks to explanations and
> instructions are likely to be helpful.  I also wonder whether support for
> multipart/multilingual could be useful.
>
> The body is irrelevant to ACME-aware clients, so it seems like there could
> be a lot of freedom in how this is constructed.
>
Yes, that's what I was referring to.

> Most email clients automatically convert HTTPS URLs to hyperlinks, which
> should make the silly schemes I'm imagining possible, but not very
> attractive, for ordinary users.
>
>> Best Regards,
>>
>> Alexey
>>
>> I assume this is deliberate, perhaps because of a desire to use short-TTL
>> S/MIME certificates that would be impractical to provision manually, but
>> the draft doesn't mention a rationale.
>>
>> On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich <rsalz=
>> [email-masked] <40akamai.com@dmarc..ietf.org>> wrote:
>>
>>> If anyone wants to be a document shepherd, please contact the chairs.
>>>
>> Best Regards,
>
> Alexey
>
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 3 May 2020 01:36:08 -0400

> unnecessary barrier to adoption.

Are you expecting humans to be the primary interaction point? It almost
seems that ensuring human unfriendliness is a feature, not a bug, towards
the goal of automation.

This structure seems especially important if it has a chance to be adopted
by publicly trusted CAs. One of the big concerns with existing validation
approaches is bodies that are rich-text with links used for approval, and
for which anti-spam or scanning engines inspect (“click”) and cause
improper authorizations. The more structure, the better, towards preventing
accidental authorizations.

>>> short-TTL S/MIME certificates that would be impractical to provision
>>> manually, but the draft doesn't mention a rationale.
>>>
>>> [email-masked]..org <40akamai.com@dmarc..ietf.org>> wrote:
>>>
>> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 4 May 2020 13:48:26 -0400

On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <[email-masked]> wrote:

>>> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov <
>>> [email-masked]> wrote:
>>>
>>>> Hi Ben,
>>>>
>> My concern is that users will not know what to do if they receive an
>> email whose subject line is "ACME: awlkNSdpijawrfz...".  Users are used to
>> seeing emails whose subject line is "Please verify your email address" or
>> "Confirm your email".  (My inbox is full of them.)  I see no reason to
>> disallow that here.
>>
> Are you expecting humans to be the primary interaction point?
>

Ideally, ACME-aware mail clients will handle these messages in some
beautiful, mostly-invisible way, but mail clients don't update as fast as
browsers.  Even many years after most users have ACME-aware clients, I
think a sizable fraction will have non-aware clients.

It almost seems that ensuring human unfriendliness is a feature, not a bug,
> towards the goal of automation.
>

That was my expectation after reading draft-06, but Alexey explained that
human-friendliness was in-scope, hence my suggestions.

> improper authorizations.

According to this draft, authorization requires sending a specially formed
reply email, so I think the risk of a scanning engine accidentally
authorizing is low.

The more structure, the better, towards preventing accidental
> authorizations.
>>>> [email-masked]...org <40akamai.com@dmarc..ietf.org>> wrote:
>>>>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 5 May 2020 16:18:57 +0100

Hi,

On 03/05/2020 06:36, Ryan Sleevi wrote:
>
> On Sat, May 2, 2020 at 2:11 PM Ben Schwartz 
> <bemasc=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             Hi Ben,
>>
>>>             Section 3 says token-part1 "contains at least 64 bit of
>>>             entropy", but Section 3.1 says token-part1 "MUST be at
>>>             least 64 octet long after decoding".  Is this difference
>>>             deliberate?
>>
>>>             Also 64 octets of entropy is a _lot_.  RFC 8555 says
>>>             "the token is required to contain at least 128 bits of
>>>             entropy".
>>>
>>>             The draft seems to be oriented entirely toward use with
>>>             e-mail clients that have a built-in ACME-S/MIME client. 
>>>             I'm a bit disappointed that the draft doesn't
>>>             accommodate users with "naive" email clients very well,
>>>             e.g. by allowing customized subject lines.
>>
>>             Actually, I was trying to accommodate naive email
>>             clients, but it was a fine balance trying to specify
>>             minimal requirements.
>>
>>             Can you suggest some specific text to change and then we
>>             can discuss whether or not it should be done? My thinking
>>             about the Subject header field was that I wanted to have
>>             a unique subject (so that ACME email messages are easily
>>             findable). I also wanted to allow the token in the
>>         In that case, I would suggest "... subject ending with
>>         "(ACME: <token-part1>)", where ...".  That would allow the
>>         first part of the subject (most likely to be seen by a human)
>>         to be human-readable.
>
>         As ACME servers are generating ACME challenge emails, the
>         requirement on them is stricter (they create the first message
>         in an email thread). I am tempted to leave this as is. Can you
>         think of a case where ACME servers would be unable to comply
>         with this restriction?
>
>     My concern is that users will not know what to do if they receive
>     an email whose subject line is "ACME: awlkNSdpijawrfz...".  Users
>     are used to seeing emails whose subject line is "Please verify
>     your email address" or "Confirm your email".  (My inbox is full of
>     them.)  I see no reason to disallow that here.
>
>     Mandating that the subject line be non-human-readable seems like
>     an unnecessary barrier to adoption.
>
>
> Are you expecting humans to be the primary interaction point? It 
> almost seems that ensuring human unfriendliness is a feature, not a 
> bug, towards the goal of automation.
>
> This structure seems especially important if it has a chance to be 
> adopted by publicly trusted CAs. One of the big concerns with existing 
> validation approaches is bodies that are rich-text with links used for 
> approval, and for which anti-spam or scanning engines inspect 
> (“click”) and cause improper authorizations. The more structure, the 
> better, towards preventing accidental authorizations.

Let me try to elaborate on the current choice and talk about 
alternatives. In general there are 3 ways how an ACME email challenge be 
conveyed in email:

1) In the subject line. Some structure would be helpful for automated 
software.

2) In a new header field.

3) In the body of the message, e.g. using "---BEGIN ACME CHALLENGE---" 
line in text/plain or the like.

Unfortunately all of these have their downsides:

#1 is unfriendly to users and can possibly trigger antispam processing. 
(Not sure how much of an issue the last part is)

#2 might not be accessible from libraries that don't support retrieval 
of arbitrary email header fields. (I am not sure how big of a deal this 
is, but I've heard some claims about that.) Also, non ACME aware clients 
might not be able to show this header field, making them unusable for 
manual processing.

#3 would either require use of text/plain (for simplicity of automated 
processing) or it would require HTML parser with downconversion to 
text/plain. I think the latter choice is a rather high barrier of entry 
for implementations that are not fully capable email clients, which I 
suspect would be too hight for some ACME servers.

So I am open to suggestions about the best choice. I think using some 
structured subject line (choice #1) or possibly text/plain choice #3 are 
the best. If there is a better structure for the subject header field, I 
would be happy to change the document.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 5 May 2020 16:22:11 +0100

Hi,

On 04/05/2020 18:48, Ben Schwartz wrote:
> On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>>                 Section 3 says token-part1 "contains at least 64 bit
>>>                 of entropy", but Section 3.1 says token-part1 "MUST
>>>                 be at least 64 octet long after decoding".  Is this
>>>                 difference deliberate?
>>
>>>                 "the token is required to contain at least 128 bits
>>>                 of entropy".
>>>
>>>                 The draft seems to be oriented entirely toward use
>>>                 with e-mail clients that have a built-in ACME-S/MIME
>>>                 client.  I'm a bit disappointed that the draft
>>>                 doesn't accommodate users with "naive" email clients
>>>                 very well, e.g. by allowing customized subject lines.
>>
>>                 Can you suggest some specific text to change and then
>>                 we can discuss whether or not it should be done? My
>>                 thinking about the Subject header field was that I
>>                 wanted to have a unique subject (so that ACME email
>>                 messages are easily findable). I also wanted to allow
>>                 the token in the subject for APIs that can easily
>>                 access Subject and not other header fields.
>>
>>             first part of the subject (most likely to be seen by a
>>             human) to be human-readable.
>
>             requirement on them is stricter (they create the first
>             message in an email thread). I am tempted to leave this as
>             is. Can you think of a case where ACME servers would be
>             unable to comply with this restriction?
>
>         My concern is that users will not know what to do if they
>         receive an email whose subject line is "ACME:
>         awlkNSdpijawrfz...".  Users are used to seeing emails whose
>         subject line is "Please verify your email address" or "Confirm
>         your email".  (My inbox is full of them.)  I see no reason to
>         disallow that here.
>
>         Mandating that the subject line be non-human-readable seems
>         like an unnecessary barrier to adoption.
>
>
> beautiful, mostly-invisible way, but mail clients don't update as fast 
> as browsers.  Even many years after most users have ACME-aware 
> clients, I think a sizable fraction will have non-aware clients.
Right.
>
>     It almost seems that ensuring human unfriendliness is a feature,
>     not a bug, towards the goal of automation.
>
>
> That was my expectation after reading draft-06, but Alexey explained 
> that human-friendliness was in-scope, hence my suggestions.

Obviously human-friendliness for non ACME aware email clients and ease 
of implementation in ACME aware email clients are in conflict. I would 
be happy to use some compromise if a good balance can be found.

>     adopted by publicly trusted CAs. One of the big concerns with
>     existing validation approaches is bodies that are rich-text with
>     links used for approval, and for which anti-spam or scanning
>     engines inspect (“click”) and cause improper authorizations.
>
>
> According to this draft, authorization requires sending a specially 
> formed reply email, so I think the risk of a scanning engine 
> accidentally authorizing is low.
>
Best Regards,

Alexey

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 May 2020 15:24:59 +0000

Thanks for the discussion.  I will point out that this has already moved past WGLC (I am late on the writeup and IESG submission), but in view of the pandemic messing with everyone’s schedules, and since this has not had a lot of WG commentary so far, I’d like to encourage this.  We’ll do a shorter WGLC re-review if there’s another draft.  And if we need any consensus calls (“anyone cannot live with X”) please reach out.

Hope everyone is staying safe and healthy.

From: Alexey Melnikov <[email-masked]>
Date: Tuesday, May 5, 2020 at 11:19 AM
To: Ryan Sleevi <[email-masked]>, Ben Schwartz <bemasc=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Rich Salz <[email-masked]>
Subject: Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

…..removed

Let me try to elaborate on the current choice and talk about alternatives. In general there are 3 ways how an ACME email challenge be conveyed in email:

1) In the subject line. Some structure would be helpful for automated software.

3) In the body of the message, e.g. using "---BEGIN ACME CHALLENGE---" line in text/plain or the like.

#1 is unfriendly to users and can possibly trigger antispam processing. (Not sure how much of an issue the last part is)

#2 might not be accessible from libraries that don't support retrieval of arbitrary email header fields. (I am not sure how big of a deal this is, but I've heard some claims about that.) Also, non ACME aware clients might not be able to show this header field, making them unusable for manual processing.

#3 would either require use of text/plain (for simplicity of automated processing) or it would require HTML parser with downconversion to text/plain. I think the latter choice is a rather high barrier of entry for implementations that are not fully capable email clients, which I suspect would be too hight for some ACME servers.

So I am open to suggestions about the best choice. I think using some structured subject line (choice #1) or possibly text/plain choice #3 are the best. If there is a better structure for the subject header field, I would be happy to change the document.

Best Regards,

Alexey