Re: [Acme] ACME email validation

Sebastian Nielsen <sebastian@sebbe.eu> Fri, 19 June 2020 17:26 UTC

Return-Path: <sebastian@sebbe.eu>
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 846913A0CB7 for <acme@ietfa.amsl.com>; Fri, 19 Jun 2020 10:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_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=sebbe.eu
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 Hc278_g2RtiN for <acme@ietfa.amsl.com>; Fri, 19 Jun 2020 10:25:55 -0700 (PDT)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719903A095C for <acme@ietf.org>; Fri, 19 Jun 2020 10:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:Cc:To:From; bh=GnLYgrvdwsUihB9EOhU7iXXKFYsddk4X1JpzEaGVr7E=; b=mUGSvqtZmnbxbhKAFO18FDiPby+F1V9B4AlNFMwd39ZcZvTjQJf3+W5ToFtsq9i/GnQvJjmR0p pLF5qZd1w41SuxbqwUfxabOoqxmWnMfY8l6Yaq6V5eJsJILu9zgixWL3JPJOu2lOQxrJCiv1jUUNf TbYkJCjFcz288ehAOu60=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebbe.eu with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1jmKlr-001QSa-09; Fri, 19 Jun 2020 19:25:43 +0200
Received: from [192.168.4.100] (helo=DESKTOPLO6CUS7) by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1jmKlq-001QSW-JT; Fri, 19 Jun 2020 19:25:42 +0200
From: "Sebastian Nielsen" <sebastian@sebbe.eu>
To: "'Brian Sipos'" <BSipos@rkf-eng.com>, <acme@ietf.org>
Cc: <alexey.melnikov@isode.com>
Message-ID: <000001d6465e$a97eadd0$fc7c0970$@sebbe.eu>
In-Reply-To: <MN2PR13MB3567F3E0995E58C4CDCF8CCE9F9B0@MN2PR13MB3567.namprd13.prod.outlook.com>
References: <MN2PR13MB3567F3E0995E58C4CDCF8CCE9F9B0@MN2PR13MB3567.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_118_402668323.1592587542949"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGUOlJFfAnCNf5WsQWOsr1ZLN9sDalkRRYg
X-Encryption-Target: external
Date: Fri, 19 Jun 2020 19:25:43 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/_S1chCs9kCilvzCJq0lxrrsOJJM>
Subject: Re: [Acme] =?utf-8?q?ACME_email_validation?=
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: Fri, 19 Jun 2020 17:26:01 -0000

The reason is to prevent email spoofing.
In the case of .well-known or DNS validation, or ALPN, you publish a record
where ACME fetches. That can’t be spoofed, because ACME itself searches for
the record, you can’t send ACME a record and have it accept.
 
In the email case, you instead send ACME the response back via email, which
could be spoofed, if you had access to only the ACME client, if whole the
token was given by ACME client.
 
And in the second case, if whole token was given by email, it could be a
private key that is being used for another thing – lets say signing internal
certificates via HSM, where the signing system is misused to gain SMIME
certificates by signing the token, without having access to the
corresponding ACME client where the private key is installed. By requiring 2
parts of a token, you ensure the client has access to BOTH the email inbox
AND the ACME client, AND the private key aswell.
 
To ensure that the person replying to the email BOTH have access to the
email account AND the ACME client, he must join 2 parts of a secure token,
and then use his private key to calculate the value.
 
 
Från: acme-bounces@ietf.org <acme-bounces@ietf.org> För Brian Sipos
Skickat: den 19 juni 2020 00:13
Till: acme@ietf.org
Kopia: alexey.melnikov@isode.com
Ämne: [Acme] ACME email validation
 
All,
In a recent draft I created for using ACME for non-web-PKI verification [1]
I see that there are many similarities with an earlier draft for email
verification [2]. In that email protocol, the challenge token is split into
two parts which arrive at the email validation agent through two paths:
token-part1 via the validation channel, and token-part2 via the ACME
channel.
Is there a technical reason why the token is split into two parts like this?
Is replying with the proper corresponding Key Authorization not sufficient
to prove ownership of the email address?
I don't see any similar challenge token splitting in other ACME drafts and I
don't see anything obvious in [2] to indicate why the split is useful or
needed. I also didn't see any related discussion earlier on the ACME mailing
list.
Thank you,
Brian S.
 
[1] https://datatracker.ietf.org/doc/html/draft-sipos-acme-dtnnodeid-00
[2] https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-08