Subject: [Acme] Problem with RFC8823's mail sending behavior and way to arm challenges with side effect

From: Seo Suchan <[email-masked]>
Date: Sun, 7 Nov 2021 00:00:20 +0900

After RFC8823 I though it would be trivial to apply its process for TLS 
certificate by verify email of various authoized Email address (like 
[email-masked] or email set by Whois/CAA/TXT etc...) but there is a 
problem: it's sending mail when server reply the authorization, even if 
client has no intend to use those kind of challenge. while this could be 
used as a warning mail for someone try to validate your domain, this is 
not a expected result. and even in S/Mime context if we ever made some 
other type of challenge while server still support email-reply-00, it 
will send two mail for both type of challenge message to mailing address.

I think there is two way to 'arming' a challenge with a side effect:

 1.      Make challenge that doesn't boot up until client respond to
    challenge first time. it will obviously fail because client doesn't
    get needed info to validate, but let challenge retry mechanism to
    handle that
 2.      same with 1, but use some custom payload like 'run' or
    something. we can do that when we make a new challenge protocol

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 14 Nov 2021 09:35:59 -0800

With apologies for focusing on a different aspect than you are attempting
to focus on...

> problem: it's sending mail when server reply the authorization, even if 

I am not sure I fully understand this scenario, but given my current
understanding it seems like a scheme that would not work well in practice.
In an automated issuance environment, we would typically want the thing
being used as a validation challenge to be as analogous to the actual usage
of the subsequent issued certificate as possible.  So, for a TLS
certificate, we should be making a TLS connection sith specific metadata
(e.g., SNI/ALPN), and trying to leverage some other validation challenge
that's quite divorced from the TLS channel in question risks skew between
validation procedure and actual usage.  Such skew introduces security risk,
since the "gap" between real usage and validation procedures introduce
either false positives or false negatives.

So maybe you could say a bit more about the scenario(s) you have in mind
and we could think about whether they would actually provide a useful
validation result.

Thanks,

Ben

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Seo Suchan <[email-masked]>
Date: Mon, 15 Nov 2021 12:00:31 +0900

> and we could think about whether they would actually provide a useful

mailing-to-admin address challenge for TLS certificate was example of  
mail reply challenge may used with other kind of challenges. for other 
example we may think about we may extend a send-only challenge for 
no-reply address that doesn't have inbox for sign only certificate

well the problem I see is RFC8823's mail-reply-00 challenge  so it's not 
consider other type of challenges for that upper authorization may have, 
because

1. sends its challenge email when it's created ("After responding to the 
authorization request"), not user triggered the challange

2. if it failed to send challenge email it retry will not succeed 
because client won't ever know token-p1, making it invalid- and it being 
invalid make the upper auth invalid, kills the order. (If the client 
attempts to fulfill a challenge and fails, or if there is an error while 
the authorization is still pending, then the authorization transitions 
to the "invalid" state. RFC8555 7.1.6)

and other problem is client can't know which challenge incoming mail 
triggered for because from address which doesn't required to be unique 
per challenge so acme server can reuse sending address (or just fixed it 
with static value, because challenge mail only have token-part-1 , which 
they don't know about it beforehand so if there is multiple of challenge 
mail in inbox, they will have to reply all the challenge email with 
expected sender.

(btw does smime certificate for//[email-masked] valid for 
[email-masked]?) allowing smime certificate to be verify 
challenge mail imply it is or using same sender for all challenge mails.