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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 05 May 2020 15:19 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 6567A3A0817 for <acme@ietfa.amsl.com>; Tue, 5 May 2020 08:19:37 -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 u03htCNhrMDk for <acme@ietfa.amsl.com>; Tue, 5 May 2020 08:19:35 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 11C233A0810 for <acme@ietf.org>; Tue, 5 May 2020 08:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588691974; d=isode.com; s=june2016; i=@isode.com; bh=z1GmnY0m+lmzVmnQctefX5xR2EXeNX5eRq8QA8g1CZE=; 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=JjBks82oNTVdhr8fLMB2jBD1rt4YS+C3bjQbVZav+8Cgzz+SebcM77xCdI1oDZSGTW1lFq i0QMB5No/Vx1oEHLmtzu3O3C6gKmcexLO1bwYgwfzDKmZNiEvmLWjQ5B3nTVYezKIyITUI hbFlRhQKGngLVs7kpF0wLfeNGgn9fr0=;
Received: from [172.27.250.123] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XrGEBQBqwYu6@waldorf.isode.com>; Tue, 5 May 2020 16:19:34 +0100
To: Ryan Sleevi <ryan-ietf@sleevi.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: "acme@ietf.org" <acme@ietf.org>, "Salz, Rich" <rsalz@akamai.com>
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>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <33705f69-2cbd-e2b5-6749-a02ef5da5c21@isode.com>
Date: Tue, 5 May 2020 16:18:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <CAErg=HE4_YporYSOCeT3wcah0VivH+k8gvQnfxS8w-TsKM0doQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------391F1717089861A550D37AAD"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Wm51XezoqY7KE7sJm00CesLl-18>
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:19:38 -0000

Hi,

On 03/05/2020 06:36, Ryan Sleevi 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? 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