Re: [Acme] ACME email validation

Sebastian Nielsen <sebastian@sebbe.eu> Fri, 19 June 2020 22:16 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 AD9773A0ED0 for <acme@ietfa.amsl.com>; Fri, 19 Jun 2020 15:16:49 -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 whRLoyzCuvId for <acme@ietfa.amsl.com>; Fri, 19 Jun 2020 15:16:46 -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 2B6013A0ECE for <acme@ietf.org>; Fri, 19 Jun 2020 15:16:45 -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=ONatpred7AmVaiL3DKWq8Ul8m4anQHlZALewpkKHdJw=; b=UD8mEPE7OglLP9qxnV7BYpVbRrWk64pysGvUgGN/R18iodHuHmSuGP8goiJ/QY9HQ61YVyOrBU 7Gwu2P7m+K9vKKByXy3a+UPXxgIe/a5beaMuUa9oC9NdyoRxxGR6D5qkaPNtQGryMY4xkX/sJ9pWe y2XAwOVU+vv7F7fLPHPc=;
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 1jmPJO-001RZS-Nj; Sat, 20 Jun 2020 00:16:38 +0200
Received: from [192.168.1.143] by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1jmPJO-001RZM-7g; Sat, 20 Jun 2020 00:16:38 +0200
From: Sebastian Nielsen <sebastian@sebbe.eu>
To: Brian Sipos <BSipos@rkf-eng.com>, "acme@ietf.org" <acme@ietf.org>
Cc: "alexey.melnikov@isode.com" <alexey.melnikov@isode.com>
Message-ID: <E1jmPJO-001RZM-7g@sebbe.eu>
In-Reply-To: <MN2PR13MB3567DD194C7CA98EE599F1F09F980@MN2PR13MB3567.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_130_1046156527.1592604998670"
SavedFromEmail: sebastian@sebbe.eu
Importance: normal
X-Encryption-Target: external
Date: Sat, 20 Jun 2020 00:16:38 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/AhRUYG7KaOO9WaypmK7EqMV7hz0>
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 22:16:50 -0000

No, all validation types where the client or subject sends back or submits the validation result.If the client or subject makes the validation result available, and ACME server have to search for the data in such a way the location of the result itself validate control, then you don't need the split token.
-------- Originalmeddelande --------Från: Brian Sipos <BSipos@rkf-eng.com> Datum: 2020-06-20  00:09  (GMT+01:00) Till: Sebastian Nielsen <sebastian@sebbe.eu>eu>, acme@ietf.org Kopia: alexey.melnikov@isode.com Ämne: Re: [Acme] ACME email validation 

Sebastian,


Thank you very much for this clarification. This would apply to all message exchange validation types then (including the one I'm looking into).

I notice that the email validation draft does not mention multiple attempts from different sources, which RFC8555 does discuss briefly [1]. Is there an expectation that an email validation would be attempted from multiple ACME server addresses, or is a MITM
 attack on messaging not handled because of the nature of email security?





[1] 
https://tools.ietf.org/html/rfc8555#section-10.2





From: Sebastian Nielsen
Sent: Friday, June 19, 2020 13:25
To: Brian Sipos; acme@ietf.org
Cc: alexey.melnikov@isode.com
Subject: SV: [Acme] ACME email validation







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