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

[Alexey Melnikov <[e-mail]>]

Hi,

On 03/05/2020 06:36, Ryan Sleevi wrote:
>
> On Sat, May 2, 2020 at 2:11 PM Ben Schwartz 
> <bemasc=[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Hi Ben,
>
>         On 21/04/2020 01:12, Ben Schwartz wrote:
>>
>>         On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
>>         <[e-mail]
>>         <mailto:[e-mail]>> 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?
>
>     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