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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 05 May 2020 15:22 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9A63A085E for <acme@ietfa.amsl.com>; Tue, 5 May 2020 08:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BakHgeoy3Zt7 for <acme@ietfa.amsl.com>; Tue, 5 May 2020 08:22:51 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 391513A0858 for <acme@ietf.org>; Tue, 5 May 2020 08:22:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588692168; d=isode.com; s=june2016; i=@isode.com; bh=zssR2dc6orX6UQmNRnAoxDeku7sYf5VlRFDa3jRB3s0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=frzV4VsK9M8IGtxaliV3BxuRvSc1kDRUPZc/D5iXcIQzfJy7Zg0yCNcFzstGxRyJzs935q KIa2nFcDucekJXCeDRUxTBGbwIBqodfazhwBvmLax5LoV208fP3HAx0Cq+frdnNqOSMF/Q q9O6lCH/ShcR2yS854NrbWLAesuXpkk=;
Received: from [172.27.250.123] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XrGEyABqwQfD@waldorf.isode.com>; Tue, 5 May 2020 16:22:48 +0100
To: Ben Schwartz <bemasc@google.com>, Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "acme@ietf.org" <acme@ietf.org>
References: <3703708B-4454-4AC9-87AF-961C73B1F331@akamai.com> <CAHbrMsDco31pxyBMBSdbgh5aMnttyC1G_tDTg1tz-aAzto=5dw@mail.gmail.com> <fee01750-7afb-02a7-50ee-30453805abec@isode.com> <CAHbrMsAdXvpRt2zCUn7DLNerxhZCFe4pS0TM1qzmaCUGKVYT=A@mail.gmail.com> <e188baf1-ff9f-7897-1bcb-baa94fb8ce2d@isode.com> <CAHbrMsDsW+EwGx0qzfqXn7qntB4_LqyN7jrLdkH66STeL6D02Q@mail.gmail.com> <CAErg=HE4_YporYSOCeT3wcah0VivH+k8gvQnfxS8w-TsKM0doQ@mail.gmail.com> <CAHbrMsDVx0NRXSpjvssgWW6+4w_wD1FL0rEOyp9jDmLVSAyhWw@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <c49de84f-95e0-88cc-cad7-8e53fb0a4f6f@isode.com>
Date: Tue, 5 May 2020 16:22:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <CAHbrMsDVx0NRXSpjvssgWW6+4w_wD1FL0rEOyp9jDmLVSAyhWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------A987692A034FD85967917533"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/sWqDXgg92tqDPMLEDzo_kNCcAL4>
Subject: Re: [Acme] WG last call for draft-ietf-acme-email-smime-06
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 15:22:53 -0000

Hi,

On 04/05/2020 18:48, Ben Schwartz wrote:
> On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <ryan-ietf@sleevi.com 
> <mailto:ryan-ietf@sleevi.com>> wrote:
>
>
>     On Sat, May 2, 2020 at 2:11 PM Ben Schwartz
>     <bemasc=40google.com@dmarc.ietf.org
>     <mailto:40google.com@dmarc.ietf.org>> wrote:
>
>
>         On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
>         <alexey.melnikov@isode.com <mailto:alexey.melnikov@isode.com>>
>         wrote:
>
>             Hi Ben,
>
>             On 21/04/2020 01:12, Ben Schwartz wrote:
>>
>>             On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
>>             <alexey.melnikov@isode.com
>>             <mailto:alexey.melnikov@isode.com>> 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