Subject: [Dcrup] Addition of header 'a' to Authentication-Results

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Feb 2018 01:15:13 -0500

As I'm working on an application level implementation of DKIM 
signing/verification with Ed25519 added, I find myself wishing we could put 
the algorithm in the AR header field.

I think we should because I can imagine downstream consumers wanting to treat 
rsa-sha1, rsa-sha256, and ed25519-sha256 differently.  It would also be useful 
to testing and architecture level debugging.  Can we add something like this 
to the IANA considerations section:

8.2.  Authentication Results Registration

   IANA is requested to register the following in the "Email Authentication
   Methods" registry:

   Method:  dkim

   Specifying Document:  [this document]

   ptype:  header

   Property:  a

   Value:  DKIM signing algorithm

   Status:  active

   Version:  1

I think this is much better than stuffing it in a comment.

Scott K

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 14 Feb 2018 10:29:31 -0500

> On Feb 14, 2018, at 1:15 AM, Scott Kitterman <[email-masked]> wrote:
> 
> rsa-sha1, rsa-sha256, and ed25519-sha256 differently.

Thank you for bringing this up, because I encountered this issue last week with a server I don't administer. It wasn't the end of the world, but an extra field would have been nice.

Thanks,
Stan

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 14 Feb 2018 08:17:38 -0800

> > rsa-sha1, rsa-sha256, and ed25519-sha256 differently.

I'm happy to include that amongst the other fields that we are adding in
the ARC protocol doc or it can go into the DCRUP doc.

--Kurt

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 14 Feb 2018 11:33:02 -0500

> On Feb 14, 2018, at 11:17 AM, Kurt Andersen <[email-masked]> wrote:
> 
>> On Wed, Feb 14, 2018 at 7:29 AM, Stan Kalisch <[email-masked]> wrote:
>> 
> I'm happy to include that amongst the other fields that we are adding in the ARC protocol doc or it can go into the DCRUP doc.

I'm not against it going into the ARC protocol document, but it seems simple enough that it would be nice for it to go into something intended for the Standards Track.

Thanks,
Stan

---

From: Seth Blank <[email-masked]>
Date: Wed, 14 Feb 2018 08:51:38 -0800

We were planning on defining header.s in ARC now that 7601bis is moving
forward.

But the standards track comment is well received.

Might it be worthwhile to just create a separate document, as Scott
suggested, that defines header.s and header.a together?

That would further simplify the ARC document, let these dkim property
stamps be standards track, and address the items from this thread.

Seth

On Wed, Feb 14, 2018 at 8:33 AM, Stan Kalisch <[email-masked]>
wrote:

> On Wed, Feb 14, 2018 at 7:29 AM, Stan Kalisch <[email-masked]
> > wrote:
>
>>
> I'm not against it going into the ARC protocol document, but it seems
> simple enough that it would be nice for it to go into something intended
> for the Standards Track.
>
>
> Thanks,
> Stan
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>
>

-- 

Seth Blank | Director of Industry Initiatives

E: [email-masked] | P: 415.894.2724

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 15 Feb 2018 00:43:23 -0500

I think header.a could either be trivially added to the pending DCRUP document 
or handled by 7601bis, but I think it's out of scope for the ARC working 
group, which is where I understand 7601bis is being discussed currently.

It could also be a separate document, but I don't think it really warrants 
that.  If it is decided that's the best path, I don't mind writing it.

Someone (I'd guess msk, but I'm not picky) decide which path is best.  I'll be 
glad to help however.

Scott K

On Wednesday, February 14, 2018 08:51:38 AM Seth Blank wrote:
> >> > On Feb 14, 2018, at 1:15 AM, Scott Kitterman <[email-masked]>
> >> 
> >> wrote:
> >> > signing/verification with Ed25519 added, I find myself wishing we could
> >> 
> >> put
> >> 
> >> > I think we should because I can imagine downstream consumers wanting to
> >> 
> >> treat
> >>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Feb 2018 12:24:51 +0100

> group, which is where I understand 7601bis is being discussed currently.

The algorithm could be deduced from the selector if one takes the bother to
retrieve and parse that record.  If it is a useful addition to A-R header
fields, by the same token it would be useful to read the algorithm in aggregate
feedback records.  As it introduces the new algorithm, dcrup-dkim-crypto can
meaningfully make both additions.

jm2c
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 15 Feb 2018 07:43:39 -0500

On Thursday, February 15, 2018 12:24:51 PM Alessandro Vesely wrote:
> > I think header.a could either be trivially added to the pending DCRUP
> > document or handled by 7601bis, but I think it's out of scope for the ARC
> > working group, which is where I understand 7601bis is being discussed
> > currently.
> fields, by the same token it would be useful to read the algorithm in
> aggregate feedback records.  As it introduces the new algorithm,
> dcrup-dkim-crypto can meaningfully make both additions.

Only in part.  You can distinguish rsa and ed25519 from the DNS record, but 
not rsa-sha1 versus rsa-sha256. 

I agree it would be useful in DMARC FBR, but I think that should be dealt with 
separately.

Scott K

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 15 Feb 2018 12:54:25 -0500

> On Feb 15, 2018, at 7:43 AM, Scott Kitterman <[email-masked]> wrote:
> 

And, not surprisingly at all, it was the distinction between the latter two I was most interested in.

Thanks,
Stan

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2018 15:01:33 -0500

>group, which is where I understand 7601bis is being discussed currently.

Maybe, maybe not.  ARC is deliberately adapting as much of DKIM as it can,
so if there's a .a item for DKIM there's likely to be one for ARC, too.

---

From: Seth Blank <[email-masked]>
Date: Thu, 15 Feb 2018 20:34:30 +0000

> so if there's a .a item for DKIM there's likely to be one for ARC, too.

I concur. Knowing what algorithm was used will also be beneficial for
ARC-MULTI.

I have no problem adding header.a to the IANA considerations in ARC- but we
probably need to take this discussion to the DMARC working group list for
consideration before I make that change.

The only item to note is that would make these registrations experimental
as opposed to standards track.

Any objections to moving to DMARC WG for consideration in the ARC spec?

Seth

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 15 Feb 2018 16:10:57 -0500

> On Feb 15, 2018, at 3:34 PM, Seth Blank <[email-masked]> wrote:
> 
> I concur. Knowing what algorithm was used will also be beneficial for ARC-MULTI.
> 
> I have no problem adding header.a to the IANA considerations in ARC- but we probably need to take this discussion to the DMARC working group list for consideration before I make that change.
> 
> The only item to note is that would make these registrations experimental as opposed to standards track.
> 

Unless the WG (or WGs) thinks it's onerous, I would personally prefer the registrations be tied to the standards track, available to incorporate into the experimental ARC spec.

Thanks,
Stan

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 15 Feb 2018 22:36:38 +0000

On February 15, 2018 9:10:57 PM UTC, Stan Kalisch <[email-masked]> wrote:
>> I have no problem adding header.a to the IANA considerations in ARC-
>but we probably need to take this discussion to the DMARC working group
>list for consideration before I make that change.
>> 
>> The only item to note is that would make these registrations
>experimental as opposed to standards track.
>> 
>Unless the WG (or WGs) thinks it's onerous, I would personally prefer
>the registrations be tied to the standards track, available to
>incorporate into the experimental ARC spec.

+1.  There's nothing experimental about this.

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 15 Feb 2018 17:51:21 -0800

> +1.  There's nothing experimental about this.

I agree - and there seems to be a bit of a weirdness about what IANA
actions would be related to experiments anyway. Somewhat like the failure
to register all of the DKIM ptypes in the first place :-) I know that lots
of folks will happily report unregistered ones without concern for the lack
of IANA registration.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 16 Feb 2018 03:01:11 -0500

> Any objections to moving to DMARC WG for consideration in the ARC spec?

I did it slightly differently.  I proposed 7601bis changes there.  

Scott K

---

From: Stan Kalisch <[email-masked]>
Date: Fri, 16 Feb 2018 10:22:00 -0500

> I did it slightly differently.  I proposed 7601bis changes there.

This was my own feeling on where it seems to best fit, since the point of 7601bis is to basically lend ARC a helping hand from the standards track.  Thanks for this.

Stan

---

From: Hector Santos <[email-masked]>
Date: Fri, 16 Feb 2018 10:27:57 -0500

On 2/15/2018 8:51 PM, Kurt Andersen wrote:
> On Thu, Feb 15, 2018 at 2:36 PM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     On February 15, 2018 9:10:57 PM UTC, Stan Kalisch
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >
> actions would be related to experiments anyway. Somewhat like the
> failure to register all of the DKIM ptypes in the first place :-) I
> know that lots of folks will happily report unregistered ones without
> concern for the lack of IANA registration.

And that shouldn't be an issue as long as it matches the same 
"namespace" as the header, e.g. like for your DKIM header:

Authentication-Result: dkim.winserver.com
    ...
    dkim=fail (DKIM_BODY_HASH_MISMATCH)
       header.d=drkurt.com
       header.s=20130612
       header.i=drkurt.com
       header.a=rsa-sha256;

Adding "header.a=rsa-sha256" to the DKIM= section should not be a 
technical conflict.

The technical implementation issue may occur when a failure is assumed 
due to an unexpected, unwanted, newly restricted hash.  For example, 
key has k=ed25519 and the  signature has a=rsa-sha256.  The fact that 
we are doing this hashing update will probably mean we may see more 
non-matching hashing algorithms verification results.  So maybe a 
"key.k=" field can also be added to the DKIM= namespace to help with 
evaluators or reporters why the verification failed:

Authentication-Result: dkim.winserver.com
    ...
    dkim=fail (DKIM_KEY_HASH_MISMATCH)
       header.d=drkurt.com
       header.s=20130612
       header.i=drkurt.com
       header.a=rsa-sha256
       key.k=ed25519;

My point is, you are right, whatever it takes for new implementations 
to experiment and explore this. For local evaluator consumption, local 
verifiers will add/pass whatever info as necessary.  I did it with 
DKIM ADSP/ATPS work and it will probably continue as the 
experimentation continues with no solid protocol logic and background 
yet established.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 16 Feb 2018 13:01:12 -0500

> Adding "header.a=rsa-sha256" to the DKIM= section should not be a

That's what is proposed.

>     dkim=fail (DKIM_KEY_HASH_MISMATCH)

That would require a much more invasive change.  Currently all the information 
in the A-R field is from the DKIM signature header field (thus the ptype 
header).  Taking the 'k' tag from the DNS record would need a new ptype.  
Since the only software that would know to do this would have to be updated to 
account for multiple algorithms, it would be likely that they'd at least not 
make this kind of basic error.  This kind of reporting really only has utility 
for legacy systems that are, by definition, unable to do it.

In any case, from the very beginning, DKIM has warned to ignore new algorithms 
(this is RFC 6376, but it goes back to the start of DKIM):

3.3.4.  Other Algorithms

   Other algorithms MAY be defined in the future.  Verifiers MUST ignore
   any signatures using algorithms that they do not implement.

Since this is the first time we added a new algorithm, there may be bugs, but 
modifying A-R isn't going to help us find them.

> experimentation continues with no solid protocol logic and background

It's a pretty trivial addition.  I updated the python authres module yesterday 
to accommodate this (version 1.0.2 for those that care) and it took longer to 
write a test than to write the code.

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 16 Feb 2018 16:06:03 -0500

>> Adding "header.a=rsa-sha256" to the DKIM= section should not be a

Yup.  Already implemented it on my server.

>> key has k=ed25519 and the  signature has a=rsa-sha256. ...

I agree this is overkill.  If you see verifications failing due to screwed 
up keys, it's easy enough to go back and look.

No doubt some people won't RTFM and will try and put both RSA and ED25519 
keys at the same selector, but as we all know there's an unlimited number 
of ways to do things wrong, and it's not very productive to try and guess 
what mistakes people will make.  For example, wrong key type is one kind 
of error, but two keys at the same name is a different kind of error.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Hector Santos <[email-masked]>
Date: Fri, 16 Feb 2018 21:41:35 -0500

> header).  Taking the 'k' tag from the DNS record would need a new ptype.

I'm talking about Protocol Consistency.

The point is if the local verifier/evaluator requires a recording that 
is not registered, then its going to be done, just as it was done in 
the past when AUTH-RES was incomplete per implementation basis.

It doesn't have to be about an "error."   A domain has a key policy 
for SHA256 and/or ed25519 and a signature spoof has sha1, if it's even 
possible to do, then its an immediate trap with an low overhead 
evaluation.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 16 Feb 2018 22:06:24 -0500

On 2/16/2018 4:06 PM, John R. Levine wrote:
> I agree this is overkill.  If you see verifications failing due to
> screwed up keys, it's easy enough to go back and look.

Yes,  "If you see"  well, we all don't see the same thing, unless of 
course, we establish the boundary conditions for what the protocol 
rules will be.

We have left too much fuzzy logic in our DKIM+POLICY protocol 
development over the years. Leave that to the true indeterminate 
conditions.  We have hard rules that have very low to zero false 
positives.   A new one will be HASH mismatches now that we have two 
new whelms of possible DKIM signatures; DKIM STD "v1.0" and DKIM STD 
"v1.1" that includes ed25519 and effectively eliminates sha1.  All 
that protocol logic change to be discussed in the RFC guidelines.  No 
need to leave it to ambiguity.

A implementation MAY create an evaluator where it MAY need the key 
hash policy without requiring to do yet another DNS lookup for the 
DKIM Signer Domain key record.  Policy info could be passed via 
AUTH-RES.  (Side note, add up the DNS lookups a SMTP server per 
transaction today?)

The actual DKIM verifier MAY not do the failure for the hash mismatch. 
The AUTH-RES evaluator could do this logic.

Whether it does it not, it will be the local MSA/MDA/MUA 
implementators who will decide.

> No doubt some people won't RTFM

When the "FM" is half backed, it is why we are constantly debating and 
evolving.

Thanks

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Feb 2018 20:28:54 +0000

On Thu, Feb 15, 2018 at 11:24 AM, Alessandro Vesely <[email-masked]> wrote:

> document
> aggregate

Actually yeah, this is in part why we added "header.b" back in the day.  If
you can parse A-R, you can probably parse DKIM-Signature (and the various
ARC fields), so you can extract this already, and "header.b" makes it
possible to tie them together.

-MSK