-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>,
Inveigle.net <[email protected]> writes
>As discussed briefly at IETF-124, I have created an I-D describing an
>alternate method for signing DKIM2 recipients and the next domain.
on a separate topic The draft also envisages a "DKIM2-NextDomain" which
is rather like the "pp=" tag which I proposed...
>Shortly before the meeting, Wei mentioned the potential for pp= to be
>used to delegate signing to a platform and ease migration to Ed25519. I
>had previously highlighted the benefits of explicitly delegating signing
>authority, so since there is some support for that idea I have also
>incorporated this into the DKIM2-NextDomain header.
.. exactly so
I have now been persuaded this is Not A Good Idea, so perhaps I should
rehearse that:
#1 DKIM1 has already dealt with this issue.
An ESP signs on behalf of a brand (this is standard, the email gets
two signature one for the brand that aligns with the From: and one
from the ESP to signal they have handled the email, which matters
for some feedback mechanisms, plus for general deliverability.
The ESP either provides a public key for the brand to put into their
DNS or more commonly asks for the brand to add a CNAME that points
to the ESP's DNS entry which holds the public key. Typically the ESP
will get two CNAMEs added so they can easily roll the key if needed.
#2 There is (probably) an extra DNS lookup
A verifier needs to resolve the pp= entry to determine if permission
has been granted. The ESP still needs to tell the brand what to do,
so there's still DNS things to hold the hand of the brand owner for.
If ESPs go for CNAMEs again, then there's an extra DNS fetch (that
is not parallelisable)
#3 There is risk of hijack if the brand says "X can sign as me"
There are risks in the CNAME scheme as well, but the ESP can do
checks to detect this whereas an incorrect (or just outdated! if the
brand has changed provider) pp= record may be harder to detect at an
early stage of an attack.
#4 KISS
We have a solution already (see #1) and our design philosophy has
always been to make DKIM2 as similar to DKIM1 as possible for brands
and ESPs. Everyone (and their consultants) knows how DKIM1 keys are
delegated to ESPs... let's just do the same.
>An explicit signing approval allows an ESP which currently manages user
>keys to sign the original approval using an RSA key, then re-sign the
>email and recipients using their own Ed25519 keys.
I think algorithm issues are a red herring -- multiple CNAMEs give as
much flexibility as may be needed
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaSzzWGHfC/FfW545EQLGLwCghx0ZF2413sshzAZD9VSpvbhwyFsAoKJa
OytqR6JD5OCUrId4S5BycW/w
=K8t8
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
