Re: [Acme] WG last call for draft-ietf-acme-email-smime-06
Ben Schwartz <bemasc@google.com> Mon, 04 May 2020 17:49 UTC
Return-Path: <bemasc@google.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 8C8083A0DCF for <acme@ietfa.amsl.com>; Mon, 4 May 2020 10:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4-8G8Q4tbyse for <acme@ietfa.amsl.com>; Mon, 4 May 2020 10:49:03 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBD93A0DD1 for <acme@ietf.org>; Mon, 4 May 2020 10:48:39 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id y24so464833wma.4 for <acme@ietf.org>; Mon, 04 May 2020 10:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kuQN5OBR20FTzPWqV2ETeG9dgAuZKd39YtHItDoc9dA=; b=VCELtLnX/Pj4ObPFVIsLu7+rtNGO9S0rJpH7nYi5CbL83RWvdRbJ7Ce0LjpK2YHaFo osB14D8M1pF4L0NSx/fAqs84GcBvQ+UxwdHO3x9KJBS7HU1CzXXewDe2+vytvNbt4ndF m7zPtLUNirWX7WPrgtIqmxx7zmk5/FunWX3xIY+39dcWnZn98XvLYP08/gn7nKVOYS84 nHqvoEZesJ+NHZd0232vEFg30DaOVBvLH0KARfDNq386+VEAYEwA/DuFEqyBMVaDnLyH ue8fEN4geV+vIm03WFVCxRPDUZtRUJH6m09GSb1rCM3IRpMfMKqqSPZlWB2fEioSN4EF ofGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kuQN5OBR20FTzPWqV2ETeG9dgAuZKd39YtHItDoc9dA=; b=ZFTHza6OOF2A+vLw9/cr1/Fn3zEbZWxV6izGB+J/hwr37cs+DWyG1W5A+EUkVllDef Y/RsfBRWhd/y4ls7N1EEHKf1eQcH1Zz85a1sQlsKW5Q3y9EjZA0P1SK8J7SGkBQFfHxJ foPVTGsR48zywPmOIMTfT65pyr1X/CFGT+K0Ec2nT6R0APX6cqe0J3obmJgVUfB196ER CfGXESuoFC2skKSRWQf62kH9JzGJXeRBX0mzPU/QZcQqhXTpO2Aubgtc+pYpqhrDmQ5B ilCgUDz7ZZL4zo2AVk2aDC0dv3zfJaDtjN0flZ67ixpu6l+pI+F1sJdqeGZzWgxLtIvi IYAQ==
X-Gm-Message-State: AGi0Pub+xJzch5ostF94YvaW2XzsQRAT1ymcCFnM/0LyHo5NGMQDw9A/ EBTXxGyzJPZvgZOuVwuHAH11AEwajn351hD7zG8ldg==
X-Google-Smtp-Source: APiQypLBIoqdCVea1sIqoLkdZU4FWuDBikPbjw06VogfDn5ZtBAA3Ugg9Qufq+IL0aai7SOa/tEWR1OJZZFtMEs8+Nw=
X-Received: by 2002:a1c:6a08:: with SMTP id f8mr15097843wmc.132.1588614517846; Mon, 04 May 2020 10:48:37 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAErg=HE4_YporYSOCeT3wcah0VivH+k8gvQnfxS8w-TsKM0doQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 04 May 2020 13:48:26 -0400
Message-ID: <CAHbrMsDVx0NRXSpjvssgWW6+4w_wD1FL0rEOyp9jDmLVSAyhWw@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, "Salz, Rich" <rsalz@akamai.com>, "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000108b3d05a4d624e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/MC-Le4HMehMlaEuHbZDQFULofSI>
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: Mon, 04 May 2020 17:49:06 -0000
On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote: > > > On Sat, May 2, 2020 at 2:11 PM Ben Schwartz <bemasc= > 40google.com@dmarc.ietf.org> wrote: > >> >> >> On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov <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> 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. 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. 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. > > 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. >>> >> Yes, that's what I was referring to. >> >>> 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= >>>> 40akamai.com@dmarc.ietf...org <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 >>> >>> >>> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >
- [Acme] WG last call for draft-ietf-acme-email-smi… Salz, Rich
- Re: [Acme] WG last call for draft-ietf-acme-email… Ben Schwartz
- Re: [Acme] WG last call for draft-ietf-acme-email… Salz, Rich
- Re: [Acme] WG last call for draft-ietf-acme-email… Ryan Sleevi
- Re: [Acme] WG last call for draft-ietf-acme-email… A. Schulze
- Re: [Acme] WG last call for draft-ietf-acme-email… Salz, Rich
- Re: [Acme] WG last call for draft-ietf-acme-email… Alexey Melnikov
- Re: [Acme] WG last call for draft-ietf-acme-email… Ben Schwartz
- Re: [Acme] WG last call for draft-ietf-acme-email… Alexey Melnikov
- Re: [Acme] WG last call for draft-ietf-acme-email… Ben Schwartz
- Re: [Acme] WG last call for draft-ietf-acme-email… Ryan Sleevi
- Re: [Acme] WG last call for draft-ietf-acme-email… Ben Schwartz
- Re: [Acme] WG last call for draft-ietf-acme-email… Alexey Melnikov
- Re: [Acme] WG last call for draft-ietf-acme-email… Alexey Melnikov
- Re: [Acme] WG last call for draft-ietf-acme-email… Salz, Rich