Subject: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 May 2020 19:21:55 +0200

Hi all,

consider the famous incipit:

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322], which
   they are authorized to use.

The question is, what responsibility is being claimed?  Some sites allow
authenticated users to use any From:, but are able to find out who the actual
author was, if needed.  Other sites only sign if the From: matches the actual
user, or at least its domain part.  Still others just sign everything.

Discussions about what kind of assurance would a signature imply are rather
frequent.  At least, specifying an aim= tag should shred some light on the
various possibilities.

Tagging keys with aim= would allow senders to choose an appropriate selector
under different circumstances.  Some mail sites use different sending IP
addresses to meet a similar purpose.  Others use different domain names, opaque
chunks of base64 data, or X-Google-DKIM-Signatures.  An aim= would serve a
similar purpose in a more open manner, introducing yet another means to discern
among different mail flows.

Comments?

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 2020 10:30:10 -0700

On 5/11/2020 10:21 AM, Alessandro Vesely wrote:
> The question is, what responsibility is being claimed?  
...
> under different circumstances.

If signers want to have a standardized means of indicating the 
fine-grained semantics behind their signature, they can do that without 
modifying DKIM.

Rather, define and use a header field that specifies DKIM signing 
policy.  Cover it with the DKIM signature, of course.

The only interesting part of this task is deciding on a standard set of 
policy labels.

Oh, and then figuring out why and how they are useful to provide...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 May 2020 11:23:12 -0700

On Mon, May 11, 2020 at 10:30 AM Dave Crocker <[email-masked]> wrote:

> ....

Indeed; why would I believe what any given domain claims in this tag?

If the response to that is that you will trust only what certain domains
say here, then you probably already know the equivalent of what's in the
tag anyway.

-MSK

---

From: Damon <[email-masked]>
Date: Mon, 11 May 2020 15:52:28 -0400

Trying to follow this thread...

I am unclear as to what problem this (aim=) is trying to solve... or is
this only to add a layer of (potentially ignored) definitions?

Regards,
Damon

On Mon, May 11, 2020 at 2:23 PM Murray S. Kucherawy <[email-masked]>
wrote:

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 May 2020 13:33:58 -0700

On 5/11/20 10:30 AM, Dave Crocker wrote:

> fine-grained semantics behind their signature, they can do that
> without modifying DKIM.
>

If this is expressing semantics for the DKIM signature, it's also likely
that there are going to be multiple DKIM signatures on the message with
different semantics. There might then be multiple instances of the
header field, and it would be difficult to associate each signature with
the appropriate semantics header field, except in the specific case
where there is only one specific semantics header field and all
signatures use either that or the default.

There might also be the situation where a domain wants to delegate a key
to a third party that can only have a subset of semantics, e.g., "this
was sent by our advertising partner" vs. "this comes from our own
staff". That's a reason to tag the key; otherwise, it would be
preferable to tag the signature itself. This would be an extension, not
a modification of DKIM.

>
> The only interesting part of this task is deciding on a standard set
> of policy labels.
>

I'm also not clear on what the aim= tag would be asserting, why it would
be trustable by a verifier, and how this would be useful to a verifier,
and would like to hear more about that.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 May 2020 15:08:15 -0700

On 5/11/2020 11:23 AM, Murray S. Kucherawy wrote:
> If the response to that is that you will trust only what certain
> domains say here, then you probably already know the equivalent of
> what's in the tag anyway.

Establishing a clear community desire for this and for how it is 
expected to be used seems an important hurdle to get over, with the 
question you raise nicely establishing the need (for the need...)

> signatures use either that or the default.

Tie it do the DKIM d= or d= + selector.

> There might also be the situation where a domain wants to delegate a key

Hence my suggestion that figuring out such details is where discussion 
could get interesting, if only because people will raise all sorts of 
combinatorial theories, independent of demonstrated need, and this is a 
space with lots of combinatorials...

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 May 2020 10:20:28 +0200

On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:
> Hence my suggestion that figuring out such details is where discussion could
> get interesting, if only because people will raise all sorts of combinatorial
> theories, independent of demonstrated need, and this is a space with lots of
> combinatorials...

Besides delegated keys, some other obvious classes I'd propose —without
venturing to forge English keywords— are as follows:

* 1st class personal messages (with or without From: restrictions),

* mailing lists (with or without From: rewrite),

* bulk messages (including transactional confirmations, complaints, ...),

* forwarded mail (after severe/loose antispam filtering).

Perhaps, the keywords should be dash-separated jumbles of terms chosen from a
predefined grab bag, to allow for combinations.

On Mon 11/May/2020 21:52:28 +0200 Damon wrote:
> ... or is this only to add a layer of (potentially ignored) definitions?

Adding the definitions can be useful, given that so many people wonder about
what would a DKIM signature certify.

> Indeed; why would I believe what any given domain claims in this tag?

If you trust the domain, you can as well trust their tagging.

> Oh, and then figuring out why and how they are useful to provide...

Left as an exercise to the reader?

Best
Ale
--

---

From: Steve Atkins <[email-masked]>
Date: Tue, 12 May 2020 10:31:30 +0100

> predefined grab bag, to allow for combinations.

Some prior work in this space is TEOS.

https://www.researchgate.net/publication/301324998_Trusted_Email_Open_Standard_A_Comprehensive_Policy_and_Technology_Proposal_for_Email_Reform 

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 May 2020 09:26:30 -0400

On Tuesday, May 12, 2020 5:31:30 AM EDT Steve Atkins wrote:
> > Perhaps, the keywords should be dash-separated jumbles of terms chosen
> > from a predefined grab bag, to allow for combinations.
> 
> https://www.researchgate.net/publication/301324998_Trusted_Email_Open_Standa
> rd_A_Comprehensive_Policy_and_Technology_Proposal_for_Email_Reform

I looked through it.  It is so 2003 FUSSP.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2020 10:26:08 -0400

We need to update DMARC or any other DKIM Policy proposal to seriously 
consider  3rd party signature Authorization methods.

We have wasted so much time avoiding it. Sure, it may not apply to 
all, but neither does DMARC and the push to embed a "half-baked" DMARC 
into our mail network has created a market of kludges and new security 
problems with the endorsement of the horrible RFC5322.From rewriting 
and the creation of a super complex, solve nothing, ARC concept.

The DKIM Policy needs additional tags, call it "aim=" if you like, 
thats publishes and publicly exposes the following ideas:

1) Look, I really mean it, p=reject means NO rewriting. Reject!!

2) Eh, we are flexible, please allow following domains; ietf.org,
    resign our mail. If you see "ATPS=1" that means we support
    3rd party signatures from specific and exclusive domains.

3) Please do not bypass 1 and 2 and perform a RFC5322.From destruction
    and rewrite violating our published policy and the intent of having
    DKIM Policy for exclusive mail operations. However, if you see a
    "rewrite=1" tag, then we don't mind if you rewrite the RFC5322.From
    field IFF the resigner has an exclusive policy.

Simple!

Nothing will satisfy everyone. Not DMARC or even a ATPS or TPA or 
even the DKIM Conditional Signature draft proposal.

But we need to offer it to the market to see how it will work.  It has 
already been proven that it
works.  My package does not allow restrictive domains to sign up to 
mailing lists, not can existing subscribers can post into the list. It 
becomes an Read-Only list for them.  I am not going to Rewrite.  I 
want to sleep at night.  But if ATPS or something like is supported, I 
am extremely confident it will give DMARC an immediate security boost.

I am still around here because I have a strong feeling someone more 
important than me, Maybe Valimail or some other, maybe even google, 
will eventually get the "Ah Ha" and say "hmmm, there might be 
something here, let's explore it.  It may not work for all domains, 
but I see where it can have it place with other domains."  If these 
companies, who have such a high investment and product dependency on 
DMARC as a business, I have been scratching my head why their Project 
and/or Product R&D guy is not exploring ATPS which exist today.

Those wishing to explore ATPS, use this wizard and simulator:

https://secure.winserver.com/public/wcDMARC

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 May 2020 08:48:38 -0700

> If you trust the domain, you can as well trust their tagging.

If you trust the domain, you don't need their tagging.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 May 2020 09:23:59 -0700

On 5/12/2020 8:48 AM, Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Just to explore this a bit:

      Presence or absence of 'trust' is orthogonal with /what/ is trusted.

At small scale, long-term operators know each other and know both the 
what and the whether.  At larger scale, they might develop a degree of 
trust through history but not have any way of knowing what the other 
side's signing policies are.

For reference, I think this topic is likely to be unproductive, given 
how poorly concepts and practices of policies like this seem to fare. 
But it seems interesting, gets raised periodically, and at least could 
be a cleanly-handled topic if pursued this way.  (Especially if it is 
encoded as a separate header-field...)

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 May 2020 18:30:23 +0200

> If you trust the domain, you don't need their tagging.

Why not?  I may trust gmail, say.  Yet, in order to learn what restrictions
they apply to the From: I have to create an account and try.  There is no
standard location where they declare their policy in a machine-readable manner,
and policies written in legalese are even less readable...

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 May 2020 10:09:55 -0700

> and policies written in legalese are even less readable...

What would you do with that information if you had it?

Maybe you're using a different definition of "trust" than I am.  To me, "I
trust gmail.com" means "I believe mail signed by gmail.com is legitimate",
irrespective of how they might handle their mail.

Put another way: I believe I would only reach the opinion that I "trust"
mail from a domain when I already know the thing(s) your tag(s) would tell
me.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 May 2020 20:14:11 +0200

On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
>> Why not?  I may trust gmail, say.  Yet, in order to learn what
>> restrictions they apply to the From: I have to create an account and try.
>> There is no standard location where they declare their policy in a
>> machine-readable manner, and policies written in legalese are even less
>> readable...>>
> 

I think I'd copy it to comments in the corresponding A-R header field.  That
would make A-R stanzas more eloquent.

> mail from a domain when I already know the thing(s) your tag(s) would tell

"Trust" and "legitimacy" are abstract terms deeply rooted in human senses, i.e.
hardly machine readable.  For a more pragmatic definition of trust, "I trust
gmail.com" would mean "I believe that header fields written by gmail.com are
true to life (up to transient bugs)".  In that sense, if they stated that the
From: corresponds to the login Id, I'd believe it.

Hey, what if gmail used different selectors for newcomers?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 May 2020 14:58:06 -0400

On Tuesday, May 12, 2020 1:09:55 PM EDT Murray S. Kucherawy wrote:
> > > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely <[email-masked]>
> > 
> > wrote:
> > restrictions

The implication is that such tags won't affect a deliver/don't deliver decision 
(which I think is correct - the moment it does, all my mail will be marked 
super duper urgent first class the user really wants this I swear).  

To the extent such information is useful for downstream processing (and I 
don't really know that it is, but if it is), there's no compelling need to 
complicate DKIM with this.  As Dave suggested, this could be a new header 
field.  It could be covered by a DKIM signature with the same security 
properties as if it were a part of DKIM without imposing additional complexity 
on DKIM.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 May 2020 14:59:49 -0400

> would make A-R stanzas more eloquent.

Personally, more eloquent header fields aren't a priority.  I'm confident that 
if there were somehow standardized, I wouldn't implement it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 May 2020 23:03:27 -0700

> would make A-R stanzas more eloquent.

So this is ultimately for human consumption?  Now I'm really confused.

> From: corresponds to the login Id, I'd believe it.

I think you're agreeing with me, or I'm failing to see the difference.

If you believe that header fields written by gmail.com are true to life,
what more can these tags tell you?

> Hey, what if gmail used different selectors for newcomers?

What would you do with that information?  Or given your answer above, what
would one of your users do with that information?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 13 May 2020 09:36:44 +0200

On Wed 13/May/2020 08:03:27 +0200 Murray S. Kucherawy wrote:
>>>> restrictions they apply to the From: I have to create an account and
>>>> try. There is no standard location where they declare their policy in
>>>> a machine-readable manner, and policies written in legalese are even
>>>> less readable...>>>
>> I think I'd copy it to comments in the corresponding A-R header field. 
>> That would make A-R stanzas more eloquent.>>
> 

It is a semantic addition about a question that people keeps asking.  Maybe its
usage becomes apparent once we get used to it, or maybe not.  It is the fact
that that question is frequently asked which triggered this thread and makes it
interesting.

>>> [...]

A-R details can be used to set IMAP keywords, to sort messages in different
folders, with varying colors or icons.  These techniques are quite helpful,
especially with busy mailboxes.

The destiny email messages is not a Boolean read-or-kill.

Best
Ale
--