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 protected]"
but there is no requirement for that, and exemple challange mail or
response mail both has [email protected] without and nonce part
as the acme-server's sender address.
in addition, From field of email accepts display_name
<[email protected]> format too, which would allow bypass unique address
problem entirely by using symtex this like acme-challange-a388b9bfTBgr
<[email protected]> 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.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
