Re: [Ietf-dkim] Taking Responsibility

[Steve Atkins]

> On 13 Dec 2022, at 06:02, Evan Burke  wrote:
> 
> 
> On Mon, Dec 12, 2022 at 8:49 PM Murray S. Kucherawy  > wrote:
> At a recent meeting where I heard some mass senders talk about this problem, 
> the use of "x=" as a mitigation technique was raised.  I was curious to know 
> what their experience was in terms of (a) success overall, but also (b) how 
> broadly they found "x=" to have been properly implemented by receivers.  I 
> have to admit that was some months ago and now I forget the answer; maybe 
> someone else who was there can fill in that blank.
> 
> But I'm not sure that "x=" by itself is enough, given that it takes only a 
> matter of seconds for the attack to succeed, and it seems unlikely to me that 
> the "t=" and "x=" values would ever be that close together.
> 
> 
> x= is indeed the most effective single defensive technique for many affected 
> senders whose signatures are getting replayed, but yes - in practice it's 
> still "not quite enough" even when combined with multiple other mitigation 
> techniques. That's why we're here; existing solutions come up short.
> 
> I can't speak to support for x= broadly, but as mentioned earlier these 
> replays were almost exclusively targeted at end recipients at certain large 
> mailbox providers, and I can confirm those have proper support for x=.

If people are seeing DKIM replays we should have data on the delay between the 
mail originally being sent, and it being replayed?

Cheers,
  Steve___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Evan Burke]

On Mon, Dec 12, 2022 at 8:49 PM Murray S. Kucherawy 
wrote:

> At a recent meeting where I heard some mass senders talk about this
> problem, the use of "x=" as a mitigation technique was raised.  I was
> curious to know what their experience was in terms of (a) success overall,
> but also (b) how broadly they found "x=" to have been properly implemented
> by receivers.  I have to admit that was some months ago and now I forget
> the answer; maybe someone else who was there can fill in that blank.
>
> But I'm not sure that "x=" by itself is enough, given that it takes only a
> matter of seconds for the attack to succeed, and it seems unlikely to me
> that the "t=" and "x=" values would ever be that close together.
>


x= is indeed the most effective single defensive technique for many
affected senders whose signatures are getting replayed, but yes - in
practice it's still "not quite enough" even when combined with multiple
other mitigation techniques. That's why we're here; existing solutions come
up short.

I can't speak to support for x= broadly, but as mentioned earlier these
replays were almost exclusively targeted at end recipients at certain large
mailbox providers, and I can confirm those have proper support for x=.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/12/22 8:49 PM, Murray S. Kucherawy wrote:

On Mon, Dec 12, 2022 at 5:03 PM Michael Thomas  wrote:

Note that in both cases it requires the good will of the receiver (or
client in the web case). We already have the equivalent of expired
certs
with the x= option. If senders are concerned about this, there is
already solution in the current specs.


At a recent meeting where I heard some mass senders talk about this 
problem, the use of "x=" as a mitigation technique was raised.  I was 
curious to know what their experience was in terms of (a) success 
overall, but also (b) how broadly they found "x=" to have been 
properly implemented by receivers.  I have to admit that was some 
months ago and now I forget the answer; maybe someone else who was 
there can fill in that blank.


But I'm not sure that "x=" by itself is enough, given that it takes 
only a matter of seconds for the attack to succeed, and it seems 
unlikely to me that the "t=" and "x=" values would ever be that close 
together.


I too remain skeptical that would help with the problem as well, just 
trying to point out that there exists protocol mechanisms already 
available to have the same effect as stripping signatures. They all rely 
on the good will of the initial receiver, which of course is far from 
guaranteed.


If there is any solution here, it needs to be on the sender's end.

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

Re: [Ietf-dkim] Taking Responsibility

[Murray S. Kucherawy]

On Mon, Dec 12, 2022 at 5:03 PM Michael Thomas  wrote:

> Note that in both cases it requires the good will of the receiver (or
> client in the web case). We already have the equivalent of expired certs
> with the x= option. If senders are concerned about this, there is
> already solution in the current specs.
>

At a recent meeting where I heard some mass senders talk about this
problem, the use of "x=" as a mitigation technique was raised.  I was
curious to know what their experience was in terms of (a) success overall,
but also (b) how broadly they found "x=" to have been properly implemented
by receivers.  I have to admit that was some months ago and now I forget
the answer; maybe someone else who was there can fill in that blank.

But I'm not sure that "x=" by itself is enough, given that it takes only a
matter of seconds for the attack to succeed, and it seems unlikely to me
that the "t=" and "x=" values would ever be that close together.

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/12/22 4:57 PM, Grant Taylor wrote:

On 12/11/22 8:34 AM, Dave Crocker wrote:
I think a simple -- and hopefully not too simplistic -- question to 
consider in the context of replay and other misuses of DKIM, is when 
is it reasonable to make a fresh validation effort invalid? When 
should a random, remote agent no longer be able to 'validate' the 
signature?


I'd like to draw an analogy to S/MIME signatures on messages. 
Specifically, does the signature of a signed message that validates 
today supposed to fail tomorrow just because of the relatively short 
intervening time when the signing S/MIME certificate expired?


Also, consider the scenario where a signature validates yesterday, but 
will be rejected next week after I revoke the signing certificate 
today.  There is value in re-checking signatures /after/ delivery, 
specifically to subsequently check for revocation /after/ delivery.


I don't know if the concept of my analogy is directly applicable to 
DKIM signatures, but I think it's in the ball park.


Note that in both cases it requires the good will of the receiver (or 
client in the web case). We already have the equivalent of expired certs 
with the x= option. If senders are concerned about this, there is 
already solution in the current specs.


Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Grant Taylor]

On 12/11/22 8:34 AM, Dave Crocker wrote:
I think a simple -- and hopefully not too simplistic -- question to 
consider in the context of replay and other misuses of DKIM, is when is 
it reasonable to make a fresh validation effort invalid? When should a 
random, remote agent no longer be able to 'validate' the signature?


I'd like to draw an analogy to S/MIME signatures on messages. 
Specifically, does the signature of a signed message that validates 
today supposed to fail tomorrow just because of the relatively short 
intervening time when the signing S/MIME certificate expired?


Also, consider the scenario where a signature validates yesterday, but 
will be rejected next week after I revoke the signing certificate today. 
 There is value in re-checking signatures /after/ delivery, 
specifically to subsequently check for revocation /after/ delivery.


I don't know if the concept of my analogy is directly applicable to DKIM 
signatures, but I think it's in the ball park.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Murray S. Kucherawy]

On Fri, Dec 9, 2022 at 7:08 PM Barry Leiba  wrote:

> I have no formal role here, so please just take this as a plea from a
> participant:
>
> Let's please stop bickering: it's simply hindering a productive
> discussion of a charter, and it's clear that we can have endless
> back-and-forth messages in this vein for quite some time if we let
> ourselves.  Please, let's not let ourselves.
>

I concur.  The bickering has resulted in a growing string of people who are
not willing to chair the reconstituted working group because this is what
they'd have to spend time dealing with.  As a result, this work will not
get off the ground if these impulses cannot be controlled.

If necessary, this list can be made into a moderated one, which will
significantly slow the dialog as things must wait in the moderator queue,
with holidays and vacations imminent.  Please let's not be forced in that
direction.

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/10/2022 2:15 PM, Al Iverson wrote:

That the charter said "during transit" is a perfectly fine and
accurate response that misses the point slightly -- that other folks
did and do see the value of post-transit use of DKIM, and that there
is significant usage of it in this way today, and to me, it seems
unreasonable to wholly discount that. Perhaps the documentation
doesn't align with common usage. Point granted, but simply holding up
a sign that says that and implying that this thus solves some level of
the problem doesn't seem right to me. There'd be an awful lot of
existing, current usage to unwind there to get back to your desired
square one, and I'd argue that there's value and utility to lose by
doing so.


There is usage that is reasonable, in terms of the technology, 
administration, and operations involving DKIM.  And then there is usage 
that is not reasonable.  On the basis of only DKIM, for example, making 
assertions about the authenticity of the rfc5322.From field contents is 
something that is often cited but never valid.  So we need some care in 
considering which uses to cover here and which to ignore or even 
explicitly exclude.


I think a simple -- and hopefully not too simplistic -- question to 
consider in the context of replay and other misuses of DKIM, is when is 
it reasonable to make a fresh validation effort invalid? When should a 
random, remote agent no longer be able to 'validate' the signature?


This does not have any effect on how to handle results from an earlier 
validation, but only later retrieval and use of the public key, I think.


So let's at least distinguish between post-delivery validation and 
post-delivery use of an earlier validation.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/10/2022 5:04 PM, Michael Thomas wrote:

What point you are trying to make belittling our contribution


DKIM is objectively an evolution of DomainKeys.  The list I cited that 
evaluated differences between DomainKeys and DKIM serves to make that 
pretty clear.


I think that history is worth noting because it considerably extends the 
experiential base for DKIM's goals and details.  The nature of the 
changes made in the IETF-related effort aren't irrelevant, but as my 
list shows, neither were they fundamental.


You dismissed the list because I wrote it -- since ad hominem appears to 
have a fluid definition -- and did so without engaging with its substance.


I invited you to show a similar comparison with IIM.  For some reason, 
you think that's unreasonable.


An invitation to provide objective information is not an attack. It is, 
however, a focus on substance.


I'm pretty sure that's allowed here.  At least sometimes.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/10/2022 5:04 PM, Michael Thomas wrote:
But that was evident from the beginning with you telling us that you 
know better what was in our heads then we did.



Michael, I didn't do any such thing.  That is one of a number of 
interpretations that you've invented.


I made some first-person assertions of fact -- since I was there, too, 
it's not unreasonable for me to do that.


In spite of my making no reference to you, you somehow decided that I 
was making a statement about what was in your brain.


For reasons that might be obvious by now, I'd never do that.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/10/22 4:31 AM, Dave Crocker wrote:

On 12/9/2022 9:25 PM, Michael Thomas wrote:
Yeah, your own website. Sorry if I don't give this any credence. 


I thought you were insisting that ad hominems stop.

In any event, the reference is to a list of factual comparisons. They 
are objectively true or false.


Feel free to focus on substance and not personality.

The fact that you think that the lack of a comparison between IIM and 
DKIM tells us something is ridiculous. I have no idea whether anybody 
did such a comparison, but who cares if they didn't? What point you are 
trying to make belittling our contribution is a complete mystery. Your 
assertions about timing, etc in an effort to discredit us are factually 
incorrect. And of course it's a personal attack since it's just trying 
to attack the your interlocutors: see mystery. But that was evident from 
the beginning with you telling us that you know better what was in our 
heads then we did. You are not the gatekeeper of DKIM history and never 
have been. Nobody is. Stop these silly attacks.


Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Al Iverson]

> Interesting bit from what appears to be the original draft charter,
> circulated at the DKIM BOF, November 2005:
>
> > The DKIM working group will produce specifications
> > that permit authentication of message headers during transit,

DKIM signature headers have effectively become a type of logging, used
for troubleshooting multiple things that ultimately relate to how the
message was perceived during transit. Being able to troubleshoot
transit issues surely has a reasonable requirement to be able to
access information like signatures and headers post transit, and I
don't think the fact that this bit of the charter necessarily
contradicts that. How would "during transit"  imply that header
information should be removed/deleted/handled post-transit in a
certain way different from today, especially given the common use case
of using it to troubleshoot what happened during transit? I don't see
an incompatibility here; it feels like a stretch to me.

That the charter said "during transit" is a perfectly fine and
accurate response that misses the point slightly -- that other folks
did and do see the value of post-transit use of DKIM, and that there
is significant usage of it in this way today, and to me, it seems
unreasonable to wholly discount that. Perhaps the documentation
doesn't align with common usage. Point granted, but simply holding up
a sign that says that and implying that this thus solves some level of
the problem doesn't seem right to me. There'd be an awful lot of
existing, current usage to unwind there to get back to your desired
square one, and I'd argue that there's value and utility to lose by
doing so.

Cheers,
Al Iverson

-- 

Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 9:25 PM, Michael Thomas wrote:
Yeah, your own website. Sorry if I don't give this any credence. 


I thought you were insisting that ad hominems stop.

In any event, the reference is to a list of factual comparisons. They 
are objectively true or false.


Feel free to focus on substance and not personality.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[mikespecter]

Regardless of who created the protocol, it’s important to acknowledge that it 
had an effect that is actively creating harm, to the point that it’s a 
geostrategic concern. There are reasonable solutions that do not harm its 
original goal of fighting spam and spearfishing and we should pursue them. A 
group chartered to solve these problems can help. 

==Mike

> On Dec 9, 2022, at 9:48 PM, Michael Thomas  wrote:
> 
> 
>> On 12/9/22 6:14 PM, Jim Fenton wrote:
>>> On 9 Dec 2022, at 17:00, Michael Thomas wrote:
>>> 
>>> On 12/9/22 4:53 PM, Dave Crocker wrote:
 On 12/9/2022 4:41 PM, Michael Thomas wrote:
> Considering that I was one of three original designers
 You worked on Domainkeys?
 
 When Yahoo asked me to be one of their outside reviewers, for their 
 initial work, I don't recall your being involved.
 
 This was considerably before there was the first, direct effort to bring 
 things to the IETF.
 
>>> Domainkeys and IIM were convergent evolution. IIM was actually published 
>>> first. I produced the first DKIM implementation followed by Murray a day or 
>>> two later.
>> DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is 
>> DKIM. The semantics and motivation behind a DKIM signature were determined 
>> by IETF consensus when it was standardized, and isn’t necessarily what the 
>> semantics and motivation behind a DomainKeys or IIM signature were.
> 
> Exactly. It took some amount of energy to synthesis them. It is completely 
> irrelevant which came first even if it was IIM. It was teh luck of 
> coincidence that just a few miles down the road we from very different 
> vantage points can to essentially the same conclusions. Trying to make this 
> into some competition is gross. I for one was really heartened when I found 
> out about DK as it validated our thinking too. I have nothing but good 
> feelings for Mark. I think what we came up with was really special and it's 
> disgusting to try to drive a wedge between the two.
> 
> Mike
> 
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 6:14 PM, Jim Fenton wrote:

On 9 Dec 2022, at 17:00, Michael Thomas wrote:


On 12/9/22 4:53 PM, Dave Crocker wrote:

On 12/9/2022 4:41 PM, Michael Thomas wrote:

Considering that I was one of three original designers

You worked on Domainkeys?

When Yahoo asked me to be one of their outside reviewers, for their initial 
work, I don't recall your being involved.

This was considerably before there was the first, direct effort to bring things 
to the IETF.


Domainkeys and IIM were convergent evolution. IIM was actually published first. 
I produced the first DKIM implementation followed by Murray a day or two later.

DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is 
DKIM. The semantics and motivation behind a DKIM signature were determined by 
IETF consensus when it was standardized, and isn’t necessarily what the 
semantics and motivation behind a DomainKeys or IIM signature were.


Exactly. It took some amount of energy to synthesis them. It is 
completely irrelevant which came first even if it was IIM. It was teh 
luck of coincidence that just a few miles down the road we from very 
different vantage points can to essentially the same conclusions. Trying 
to make this into some competition is gross. I for one was really 
heartened when I found out about DK as it validated our thinking too. I 
have nothing but good feelings for Mark. I think what we came up with 
was really special and it's disgusting to try to drive a wedge between 
the two.


Mike


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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

Yeah, your own website. Sorry if I don't give this any credence.

Mike

On 12/9/22 7:10 PM, Dave Crocker wrote:

On 12/9/2022 6:14 PM, Jim Fenton wrote:

DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is DKIM.



Just came across this.  I don't remember when the page was first 
published, but the version date of what is there now says 2007:


*What are the differences between DomainKeys (DK) and DKIM *

www.dkim.org

MIPA-DKIM <#>

 https://www.dkim.org/info/dkim-faq.html#related 



Perhaps I am missing or misunderstanding essential points in this, but 
the lengthy list of differences look useful, but not fundamental.


I don't recall seeing a similar comparison between DKIM and IIM.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 7:08 PM, Barry Leiba wrote:

For what it's worth, I remember extensive discussions about having
signatures remain verifiable after delivery, and I remember a
significant, but not universal desire to do so.



based on a quick search, the discussions don't seem to have occurred on 
the dkim wg mailing list.


and, again, there is nothing in the specification work that reflects a 
desire to have the signature validate long after delivery.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 6:14 PM, Jim Fenton wrote:

DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is DKIM.



Just came across this.  I don't remember when the page was first 
published, but the version date of what is there now says 2007:


*What are the differences between DomainKeys (DK) and DKIM *

www.dkim.org

MIPA-DKIM <#>

 https://www.dkim.org/info/dkim-faq.html#related 



Perhaps I am missing or misunderstanding essential points in this, but 
the lengthy list of differences look useful, but not fundamental.


I don't recall seeing a similar comparison between DKIM and IIM.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Barry Leiba]

I have no formal role here, so please just take this as a plea from a
participant:
Let's please stop bickering: it's simply hindering a productive
discussion of a charter, and it's clear that we can have endless
back-and-forth messages in this vein for quite some time if we let
ourselves.  Please, let's not let ourselves.

For what it's worth, I remember extensive discussions about having
signatures remain verifiable after delivery, and I remember a
significant, but not universal desire to do so.  But I think that's
not relevant now:

1. It's not relevant to the discussion we need to have now, which is
about the proposed charter.  Any discussion of actual solutions is for
the eventual working group, and I really don't see a need to have
wording in the charter about this particular issue.

2. I don't believe the original intent should be relevant even in the
eventual working group discussion.  What's important specifically is
NOT what we thought then, but what we think NOW, with the information
we have now.  We will need to weigh proposed solutions with their
efficacy on one side of the scale and their consequences on the other,
keeping in mind current usage and current problems.

Ultimately, deciding the relevance of a particular discussion, and
moderating any such discussion, will be up to the chairs of the
working group (which, by the way, will not include me).  Let's please
leave that for when we have a working group and we have chairs with
that mission.

Barry

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 4:13 PM, Dave Crocker wrote:
DKIM's motivation was (and is) to create a noise-free channel, by 
reliably associating an accurate identifier to a message stream. This 
permits a receiver to evaluate the messages in that stream, without 
concern that it has been polluting by other (unauthorized) sources 
using that identifier.

...
The above reference to things happening in transit and some out of 
band mechanism sound interesting, but don't have much to do with the 
original DKIM work, which really was only about giving receivers a 
noise-free basis for evaluating messages associated with an identifier. 



Interesting bit from what appears to be the original draft charter, 
circulated at the DKIM BOF, November 2005:



The DKIM working group will produce specifications
that permit authentication of message headers during transit,



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 6:26 PM, Dave Crocker wrote:

On 12/9/2022 6:14 PM, Jim Fenton wrote:
The semantics and motivation behind a DKIM signature were determined 
by IETF consensus when it was standardized, and isn’t necessarily 
what the semantics and motivation behind a DomainKeys or IIM 
signature were.


So the fact that we use ._domainkeys., rather than ._dkim. is just a 
coincidence?



because it didn't matter. getting toward consensus and not sweating the 
stupid shit is much more important.


as it turns out, the KRS concept was much better given the failure of 
DNSSEC.


Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 6:14 PM, Jim Fenton wrote:

The semantics and motivation behind a DKIM signature were determined by IETF 
consensus when it was standardized, and isn’t necessarily what the semantics 
and motivation behind a DomainKeys or IIM signature were.


So the fact that we use ._domainkeys., rather than ._dkim. is just a 
coincidence?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 6:14 PM, Jim Fenton wrote:

On 9 Dec 2022, at 17:00, Michael Thomas wrote:


On 12/9/22 4:53 PM, Dave Crocker wrote:

On 12/9/2022 4:41 PM, Michael Thomas wrote:

Considering that I was one of three original designers

You worked on Domainkeys?

When Yahoo asked me to be one of their outside reviewers, for their initial 
work, I don't recall your being involved.

This was considerably before there was the first, direct effort to bring things 
to the IETF.


Domainkeys and IIM were convergent evolution. IIM was actually published first. 
I produced the first DKIM implementation followed by Murray a day or two later.

DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is 
DKIM. The semantics and motivation behind a DKIM signature were determined by 
IETF consensus when it was standardized, and isn’t necessarily what the 
semantics and motivation behind a DomainKeys or IIM signature were.


Yes, but it doesn't take away from Murray and me be all excited about 
after what we accomplished at my dinner table that day. It was truly a 
magical piece of protocol agreement when we debugged it. Murray 
understood the DK canonicalization fws better than me, I understood the 
new tags. A highlight of my life :)


Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Jim Fenton]

On 9 Dec 2022, at 17:00, Michael Thomas wrote:

> On 12/9/22 4:53 PM, Dave Crocker wrote:
>> On 12/9/2022 4:41 PM, Michael Thomas wrote:
>>> Considering that I was one of three original designers
>>
>> You worked on Domainkeys?
>>
>> When Yahoo asked me to be one of their outside reviewers, for their initial 
>> work, I don't recall your being involved.
>>
>> This was considerably before there was the first, direct effort to bring 
>> things to the IETF.
>>
> Domainkeys and IIM were convergent evolution. IIM was actually published 
> first. I produced the first DKIM implementation followed by Murray a day or 
> two later.

DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is 
DKIM. The semantics and motivation behind a DKIM signature were determined by 
IETF consensus when it was standardized, and isn’t necessarily what the 
semantics and motivation behind a DomainKeys or IIM signature were.

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 5:15 PM, Michael Thomas wrote:
And this is completely irrelevant, and a continued ad hominem. Stop it. 



Since this is the reference to a person, in the thread:

On 12/9/2022 4:41 PM, Michael Thomas wrote:
Considering that I was one of three original designers and wrote the 
first implementation, I would suggest you not tell me what was in my 
head at the time.



You appear to be telling your self to stop with the ad hominem references.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 5:06 PM, Dave Crocker wrote:

On 12/9/2022 5:00 PM, Michael Thomas wrote:
Domainkeys and IIM were convergent evolution. IIM was actually 
published first. I produced the first DKIM implementation followed by 
Murray a day or two later.


Yahoo's Domainkeys was an operational system, for at least two rounds 
of development and refinement, before discussion moved towards the 
IETF venue.


My recollection is that IIM was a proposal, but not an operational 
system.  Perhaps you can point to some documentation to the contrary?


btw, as for my note being "completely a-historic", perhaps you can 
point to substantiating material?




Wrong again. We had our signing up and running in Cisco's production 
mail before dk and before we brought it to IETF. I was surprised by 
that, but it's true as verified by Murray and Mark in private 
discussions of a blog post I wrote. The difference in time was minor and 
irrelevant, but you're the one trying to use it as a cudgel. It was 
truly convergent evolution and what allowed us in meetings you were not 
part of to agree that we should merge our proposals.


And this is completely irrelevant, and a continued ad hominem. Stop it.

Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 5:00 PM, Michael Thomas wrote:
Domainkeys and IIM were convergent evolution. IIM was actually 
published first. I produced the first DKIM implementation followed by 
Murray a day or two later.


Yahoo's Domainkeys was an operational system, for at least two rounds of 
development and refinement, before discussion moved towards the IETF venue.


My recollection is that IIM was a proposal, but not an operational 
system.  Perhaps you can point to some documentation to the contrary?


btw, as for my note being "completely a-historic", perhaps you can point 
to substantiating material?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 4:53 PM, Dave Crocker wrote:

On 12/9/2022 4:41 PM, Michael Thomas wrote:

Considering that I was one of three original designers


You worked on Domainkeys?

When Yahoo asked me to be one of their outside reviewers, for their 
initial work, I don't recall your being involved.


This was considerably before there was the first, direct effort to 
bring things to the IETF.


Domainkeys and IIM were convergent evolution. IIM was actually published 
first. I produced the first DKIM implementation followed by Murray a day 
or two later.


And of course this is an ad-hominem.

Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 4:41 PM, Michael Thomas wrote:

Considering that I was one of three original designers


You worked on Domainkeys?

When Yahoo asked me to be one of their outside reviewers, for their 
initial work, I don't recall your being involved.


This was considerably before there was the first, direct effort to bring 
things to the IETF.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 4:13 PM, Dave Crocker wrote:
The concern was and is generally about the broad messaging category 
called spam, and not specifically or solely the sub-category called 
phishing.


The above reference to things happening in transit and some out of 
band mechanism sound interesting, but don't have much to do with the 
original DKIM work, which really was only about giving receivers a 
noise-free basis for evaluating messages associated with an identifier.


The concern for post-delivery evaluation and some sort of follow-on 
actions associated with 'taking responsibility' were not part of the 
DKIM development effort.  There is nothing in DKIM's development that 
was intended -- nor do I recall discussion -- for post-delivery 
forensics or non-repudiation.  And article I cited, as well as the 
replay problem, demonstrate basic problems with such a use of it.


This is completely a-historic. Considering that I was one of three 
original designers and wrote the first implementation, I would suggest 
you not tell me what was in my head at the time. We were very 
transparent about our concerns about phishing and in particular 
spear-phishing. It was not discussed at the time because nobody was 
talking about cutting secondary validators out of the equation. Plus, 
protocols don't need to specifically envision all of their possible uses 
up front and preclude all others.


I read that article ages ago. I didn't agree with it then, I don't agree 
with it now. If you want "replay protection", email is not the vehicle. 
"Replay" has been a basic feature of email for more than 40 years.


Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Dave Crocker]

On 12/9/2022 9:36 AM, Michael Thomas wrote:
A lot of the early motivation for DKIM was that it might be helpful 
for combating phishing. 
At the time tons of email providers were open relay sewers. What DKIM 
allowed is that you could at least determine which domain was sending 
it if they signed. Ideally you want to catch the phishing before it 
hits the inbox, but obviously some of it is going to get through. A 
user might not realize for weeks or months that a message was an 
attack and that's doubly true if it was successful. One of the 
original goals was that the sending domain could theoretically take 
responsibility for sending the mail. It was never defined what that 
might entail but since a protocol was never envisioned for this to 
happen in transit, it was tacitly assumed that it was some out of band 
mechanism, like oh say, sending mail to abuse@ or something like that. 
They could then see that it was really from them and take action on 
the user who sent it. That's especially true when submission became 
the norm.


If the signature was stripped out of the mail, it gives an easy out 
for the sending domain to disclaim its involvement. That defeats the 
entire utility of taking responsibility. That's a problem, and we 
shouldn't be stripping out perfectly valid functionality.



DKIM's motivation was (and is) to create a noise-free channel, by 
reliably associating an accurate identifier to a message stream. This 
permits a receiver to evaluate the messages in that stream, without 
concern that it has been polluting by other (unauthorized) sources using 
that identifier.


The specification's language about "some responsibility" is 
intentionally vague about the nature and degree of that responsibility.  
So, for example, the semantics of DKIM do not at all mean that the 
identifier that is attached is the (or even 'a') sender, per se.  Not 
the author, not the originating MTA, and not necessarily any other 
relay.  That the identifier is often associated with one or another such 
entity is something entirely outside of the DKIM specification.


The concern was and is generally about the broad messaging category 
called spam, and not specifically or solely the sub-category called 
phishing.


The above reference to things happening in transit and some out of band 
mechanism sound interesting, but don't have much to do with the original 
DKIM work, which really was only about giving receivers a noise-free 
basis for evaluating messages associated with an identifier.


The concern for post-delivery evaluation and some sort of follow-on 
actions associated with 'taking responsibility' were not part of the 
DKIM development effort.  There is nothing in DKIM's development that 
was intended -- nor do I recall discussion -- for post-delivery 
forensics or non-repudiation.  And article I cited, as well as the 
replay problem, demonstrate basic problems with such a use of it.



d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [Ietf-dkim] Taking Responsibility

[Michael Thomas]

On 12/9/22 3:29 PM, Grant Taylor wrote:

On 12/9/22 10:36 AM, Michael Thomas wrote:
One of the original goals was that the sending domain could 
theoretically take responsibility for sending the mail. It was never 
defined what that might entail but since a protocol was never 
envisioned for this to happen in transit, it was tacitly assumed that 
it was some out of band mechanism, like oh say, sending mail to 
abuse@ or something like that. They could then see that it was really 
from them and take action on the user who sent it. That's especially 
true when submission became the norm.


If the signature was stripped out of the mail, it gives an easy out 
for the sending domain to disclaim its involvement. That defeats the 
entire utility of taking responsibility. That's a problem, and we 
shouldn't be stripping out perfectly valid functionality.


This seems very reminiscent of the non-repudiation that S/MIME / PGP 
signatures provide.  With the difference being that S/MIME / PGP 
signatures operate with user granularity, while DKIM operates with 
host (or domain if keys are shared among hosts) granularity.


Is that an accurate take away from your statements Mike?

I'm not sure I understand the exact technical definition of 
non-repudiation so I'll not go out on a limb, but i'm saying that some 
use cases require that the signature survive for at least some amount of 
time. How much time is a good question. But frankly this has always been 
under the control of the sender since it can always unpublish the 
selector key.


As for this talk about removing the signature at the MDA for "replay 
protection", what makes people think they can't find MDA's that don't (= 
all now) or can't set one up?


Mike

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

Re: [Ietf-dkim] Taking Responsibility

[Grant Taylor]

On 12/9/22 10:36 AM, Michael Thomas wrote:
One of the original goals was that the sending domain could 
theoretically take responsibility for sending the mail. It was never 
defined what that might entail but since a protocol was never envisioned 
for this to happen in transit, it was tacitly assumed that it was some 
out of band mechanism, like oh say, sending mail to abuse@ or something 
like that. They could then see that it was really from them and take 
action on the user who sent it. That's especially true when submission 
became the norm.


If the signature was stripped out of the mail, it gives an easy out for 
the sending domain to disclaim its involvement. That defeats the entire 
utility of taking responsibility. That's a problem, and we shouldn't be 
stripping out perfectly valid functionality.


This seems very reminiscent of the non-repudiation that S/MIME / PGP 
signatures provide.  With the difference being that S/MIME / PGP 
signatures operate with user granularity, while DKIM operates with host 
(or domain if keys are shared among hosts) granularity.


Is that an accurate take away from your statements Mike?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Taking Responsibility

[Michael Thomas]

A lot of the early motivation for DKIM was that it might be helpful for 
combating phishing. At the time tons of email providers were open relay 
sewers. What DKIM allowed is that you could at least determine which 
domain was sending it if they signed. Ideally you want to catch the 
phishing before it hits the inbox, but obviously some of it is going to 
get through. A user might not realize for weeks or months that a message 
was an attack and that's doubly true if it was successful. One of the 
original goals was that the sending domain could theoretically take 
responsibility for sending the mail. It was never defined what that 
might entail but since a protocol was never envisioned for this to 
happen in transit, it was tacitly assumed that it was some out of band 
mechanism, like oh say, sending mail to abuse@ or something like that. 
They could then see that it was really from them and take action on the 
user who sent it. That's especially true when submission became the norm.


If the signature was stripped out of the mail, it gives an easy out for 
the sending domain to disclaim its involvement. That defeats the entire 
utility of taking responsibility. That's a problem, and we shouldn't be 
stripping out perfectly valid functionality.


Mike

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