Subject: [Acme] RFC8823: how clients know it challange mail came for is their challange, not attackers?

From: Seo Suchan <[email-masked]>
Date: Sun, 30 Jan 2022 18:13:42 +0900

I noticed there is nothing that in RFC8823 client has no way to ensure 
incomming acme-challange mail is for their challange. then it's trivial 
to DoS a email challange: attacker just have to spem order certificates 
for that email from same server then renewal is likely to happen, then 
client must blindly guess single one and reply (as server only expects 
single mail and ignore rest). while token-part 2 will stop attacker from 
get valid certificate, this flooded mailbox will make client impossible 
from get cert from desierd ACME server. the exemple challange object 
send to the client bypass this problem by using a nonce-looking mail 
address to expect the challange come from

  > "from": "[email-masked]"

but there is no requirement for that, and exemple challange mail or 
response mail both has [email-masked] without and nonce part 
as the acme-server's sender address.

in addition, From field of email accepts display_name 
<[email-masked]> format too, which would allow bypass unique address 
problem entirely by using symtex this like acme-challange-a388b9bfTBgr 
<[email-masked]> in from field of both challange object and 
mail itself, but as this field is

The challenge object also contains the "from" field, with the email
         address that would be used in the From header field of the
         "challenge" email message

there is no rfc2119 keywords so this isn't something enforced for 
challange object

but challange email does require it to be email address

	3.1.A.2.  The From header field MUST be the same email address as specified
        		in the "from" field of the challenge object.

this display address format isn't a 'email address' so

but I think this from address thing needs a cleanup errata.