[dconn] Re: do we really need warnPhishing?

[Pawel Kowalik <[e-mail]>]

Hi Sami,

response inline with [PK]

On 12.03.26 17:21, Sami Kerola wrote:
> Hello Pawel, and others,
>
> Yesterday (2026-03-11) in a change request to Domain Connect Templates
> repository README.md warnPhishing was mentioned.
>
> https://github.com/Domain-Connect/Templates/pull/846#discussion_r2916649558
>
> I do not think warnPhishing is useful in templates.  If I understood the
> rationality with that option correctly it was supposed to be used in
> combination with The Asynchronous Flow, and particularly in situations where
> some major Service Provider, such as Microsoft, can have partners who apply
> template on behalf of the Service Provider.
[PK] actually with Synchronous Flow. Asynchronous flow does not appear 
to be prone to the same kind of issue of link forging because of OAuth 
client authentication.

In the beginning domain connect didn't have signing feature at all. It 
was added later and some templates
were considered "safe" even if not using signing, if there were no 
variables in the template.

For operational reasons of some provider setups indeed signing was not 
always possible for "insecure" templates, therefore warnPhishing flag 
was added.

 From the current perspective indeed almost 90% of the templates use 
signing these days and saying: either use signing or your template is 
insecure.

This would mean declaring syncPubKeyDomain RECOMMENDED instead of 
OPTIONAL in Section 6.1.

> It feels like the above workflow assumes Service Provider syncPubKeyDomain
> cannot have per partner TXT records, for as many partners the Service
> Provider wants.  This way the Service Provider does not need to give some
> sort of master key to anyone, and can break trust relations with a partner
> when needed.
[PK] I agree it is not impossible, therefore indeed it can be left to 
these providers to find solutions to these specific problems.
>
> So what is the impact to the warnPhising?  When an apply request is not
> using public key to confirm update is coming from trusted source the update
> request should either be blocked or always warn it is suspicious.  Meanwhile
> if the signature checksum can be validated then there is no need to warn
> user.  In other words, warnPhising does not play a role in the decision
> process whether to warn or not, and therefore this option can be deprecated.
>
> Any thoughts?
>
Agree. So far it was a 3-state situation. Signed / Unsigned Secure / 
Unsigned Insecure (warnPhishing).

Changing it to 2 state is a good simplification. I am wondering if 
making it explicit by leaving warnPhishing flag and saying either 
warnPhishing or syncPubKeyDomain or syncBlock MUST be set.

This way providers who rely today on warnPhishing will keep working same 
way, and also an explicit flag in the template has less probability to 
be missed out in processing, rather than rely on absence of other flags. 
Does it make sense to you?

[1] https://stats.domainconnect.org/

Kind Regards,
Pawel