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

[Scott Kitterman]

On Tuesday, May 12, 2020 2:14:11 PM EDT Alessandro Vesely wrote:
> On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
> > On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:
> >> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> >>> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely  
wrote:
>  On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > 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.
> >>> 
> >>> 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...>>
> > 
> > What would you do with that information if you had it?
> 
> I think I'd copy it to comments in the corresponding A-R header field.  That
> 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


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Scott Kitterman]

On Tuesday, May 12, 2020 1:09:55 PM EDT Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:
> > On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> > > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely 
> > 
> > wrote:
> > >> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > >>> 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.
> > > 
> > > 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...
> 
> 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.

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


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Alessandro Vesely]

On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:
>> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
>>> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely  wrote:
 On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> 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.

>>>
>>> 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...>>
> 
> What would you do with that information if you had it?


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


> 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.


"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
-- 










___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Murray S. Kucherawy]

On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:

> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely 
> wrote:
> >> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> >>> 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.
> >>
> >
> > 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...
>

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
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Alessandro Vesely]

On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely  wrote:
>> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
>>> 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.
>>
> 
> 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
-- 






































___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Dave Crocker]

On 5/12/2020 8:48 AM, Murray S. Kucherawy wrote:
On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely > wrote:


On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
 > 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.


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



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/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Murray S. Kucherawy]

On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely  wrote:

> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > 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.
>

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

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Hector Santos]

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 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


On 5/11/2020 1:21 PM, Alessandro Vesely wrote:

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?





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Scott Kitterman]

On Tuesday, May 12, 2020 5:31:30 AM EDT Steve Atkins wrote:
> On 12/05/2020 09:20, Alessandro Vesely wrote:
> > On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:
> >> On 5/11/2020 1:33 PM, Jim Fenton wrote:
> >>> 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...
> > 
> > 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.
> 
> Some prior work in this space is TEOS.
> 
> 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


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Steve Atkins]

On 12/05/2020 09:20, Alessandro Vesely wrote:

On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:

On 5/11/2020 1:33 PM, Jim Fenton wrote:


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...


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.



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

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Alessandro Vesely]

On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:
> On 5/11/2020 1:33 PM, Jim Fenton wrote:
> 
>> 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...


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.


On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> 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.


On Mon 11/May/2020 19:30:10 +0200 Dave Crocker wrote:
> Oh, and then figuring out why and how they are useful to provide...


Left as an exercise to the reader?



Best
Ale
-- 



































___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim