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

[Alexey Melnikov <[e-mail]>]

Hi,

On 04/05/2020 18:48, Ben Schwartz wrote:
> On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <[e-mail] 
> <mailto:[e-mail]>> 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?
>
>
> 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.
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.

>     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.
>
>
> 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.
>
Best Regards,

Alexey