Subject: [Dcrup] Authentication Results and Ed25519 Signatures

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Apr 2018 14:08:43 -0400

Since I've been sending dual rsa-sha256/ed25519-sha256 signed emails for 
awhile now, I decided to look for cases where I could see how the results were 
being recorded (in some cases I'll get the mails back).  Unfortunately, most 
of them don't add an A-R header field, but I was often able to see that the 
messages were correctly scored as DKIM signed with a valid signature.  I have 
not found any cases that were problematic.

The two data points I found A-R for were Google and IETF lists (non-DCRUP 
relevant bits elided):

Authentication-Results: mx.google.com;
       dkim=neutral (no key) header.i=@kitterman.com header.s=201803e 
header.b=hxFQlnEt;

Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral
 reason="invalid (unsupported algorithm ed25519-sha256)"
 header.d=kitterman.com header.b=INr2EzUJ;

Ideally, I think a bit of what's in both should be included.  I think the IETF 
(amavisd-new) error message is very good.  I think it's completely clear 
what's going on.  I also like that Google included the selector.  I know 
201803e is a selector for an ed25519 key, so I understand "no key" means "no 
RSA key".

Does anyone else have other examples?

If anyone has another implementation they'd like to test, feel free to mail me 
off list and I'll be glad to help.

Scott K

---

From: "A. Schulze" <[email-masked]>
Date: Mon, 16 Apr 2018 21:57:13 +0200

> Does anyone else have other examples?

I also run Scott's software for some weeks. The A-R header I saw
confirm Scott's findings. I did not notice any negative impact.

Andreas

---

From: Phil Pennock <[email-masked]>
Date: Mon, 16 Apr 2018 16:11:31 -0400

> Does anyone else have other examples?

Exim 4.91 has just been released (yesterday), with support for Ed25519
(with usual library caveats).

ARC-Authentication-Results: i=1; exim.org;
        iprev=pass (smtp.spodhuis.org);
        spf=pass smtp.mailfrom=spodhuis.org;
        dkim=pass header.d=spodhuis.org header.s=d201804 header.a=rsa-sha256;
        dkim=pass header.d=spodhuis.org header.s=d201804e2 header.a=ed25519-sha256;
        dmarc=pass header.from=spodhuis.org;
        arc=none

(Note that the main exim.org MTA does not link against a pre-release
 OpenSSL, so does not handle Ed25519; our standing "next-exim" MTA
 instance, on port 26, currently does.  My own domain, spodhuis.org,
 is running on pre-release OpenSSL for all SMTP ports.)

-Phil

---

From: Seth Blank <[email-masked]>
Date: Mon, 16 Apr 2018 13:16:39 -0700

>         dmarc=pass header.from=spodhuis.org;

I think stamping header.a in the dkim A-R is the exact right way to handle
this, and I believe 7601bis provides us this ability.

-- 

Seth Blank | Director of Industry Initiatives

E: [email-masked] | P: 415.894.2724

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Apr 2018 16:38:51 -0400

On Monday, April 16, 2018 01:16:39 PM Seth Blank wrote:
> >         dkim=pass header.d=spodhuis.org header.s=d201804
> > 
> > header.a=rsa-sha256;
> > 
> >         dkim=pass header.d=spodhuis.org header.s=d201804e2
> > 
> > header.a=ed25519-sha256;
> > 

Yeah.  Jeremy Harris (Exim developer) and I collaborated on this.  Here's what 
my milter provides:

Authentication-Results: relay02; dkim=pass (Good ed25519-sha256
   signature) header.d=kitterman.com header.i=@kitterman.com
   header.a=ed25519-sha256; dkim=pass (Good 2048 bit rsa-sha256 signature)
   header.d=kitterman.com header.i=@kitterman.com header.a=rsa-sha256

I'm currently holding off on a 1.0 release of dkimpy-milter until we have the 
key format issue sorted.  It's be nice to see 7601bis move forward, too, but I 
guess that's a different list.

Scott K

---

From: Phil Pennock <[email-masked]>
Date: Tue, 17 Apr 2018 13:43:53 -0400

> guess that's a different list.

We didn't want to wait longer for Exim 4.91, so I made the call (ie,
blame me for this decision, not Jeremy who did the work): Exim currently
supports both key formats in DNS, but will drop whatever doesn't end up
officially specified by the RFC.

It's a simple length-based check on the p= section of the string; not
the cleanest but MTAs have far dirtier logic to deal with the junk
people put in DNS so justifiable for support for draft-stage features.

-Phil, Exim hat on