Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jesse Thompson]

On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
> I agree with this and have been working to recruit folks to come here. I’ll 
> also be in Brooklyn and pitching the need for participation in the IETF 
> working group from folks in the email space who are seeing issues with this. 

I'll be there and interesting in participating. As an ESP/infrastructure 
provider I can say that we are "having" the issue, but can't say that we 
"seeing" the issue since visibility is only available to anti-spammers, and 
domain owners (who receive DMARC reports). 

I recall various assertions that the reason why DMARC has been successful is 
primarily because of the Reporting benefits (and I certainly agree with this 
assertion from my background as an enterprise domain owner), while the 
Conformance benefits seem to be more elusive (as evidenced by the inconsistent 
adoption by receivers and the debates around interoperability issues with 
indirect mail streams). Of course, the Authentication benefits are provided by 
DKIM/SPF, and yet DKIM signers have no standard mechanism to receive reports of 
how their signatures are being misused. 

If people think that Reporting is the reason why DMARC has been successful, 
then could we conclude that the lack of Reporting to DKIM signers is a problem 
worth addressing?

The company I work for indexes very highly on measurability. If an initiative 
can't be measured, there is no way to measure its success, so it is very hard 
to prioritize.

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Michael Thomas]

On 8/4/23 2:29 PM, Murray S. Kucherawy wrote:

Colleagues,

On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas  wrote:

Exactly. Any proposed modifications to DKIM should be based on DKIM
itself. Anything else is off-topic. It's not like you can't
propose the
ARC modifications to DKIM in terms of DKIM itself, though all of
those
modifications have nothing to do with the current charter.


Two things:

1) Please endeavor to lower the temperature on this thread.

2) If the chairs have decided, or decide in the future, that ARC has 
been discussed and consensus is to consider that topic closed, that's 
their purview.  However, such a decision cannot be derived directly 
from the charter text I'm looking at.  In particular, this text:


"The DKIM working group will first develop and publish a clear problem 
statement.

Then, it will produce one or more technical specifications that propose
replay-resistant mechanisms. The working group will prefer solutions 
compatible
with DKIM's broad deployment, and there will be an expectation that 
these solutions
will have been through implementation and interoperability testing 
before publication."


...does not, to me, constrain the solution space to DKIM itself.  If 
there's a solution to DKIM replay outside of DKIM itself, then it's 
fair game.


Well, for starters ARC doesn't have broad deployment. But the author 
doesn't say why ARC is needed or relevant. That is the point here. *All* 
changes need to be justified including any imported mechanisms. The less 
rat holes the better. Same with the mailing list modification draft. Why 
is that even relevant?


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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Murray S. Kucherawy]

Colleagues,

On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas  wrote:

> Exactly. Any proposed modifications to DKIM should be based on DKIM
> itself. Anything else is off-topic. It's not like you can't propose the
> ARC modifications to DKIM in terms of DKIM itself, though all of those
> modifications have nothing to do with the current charter.
>

Two things:

1) Please endeavor to lower the temperature on this thread.

2) If the chairs have decided, or decide in the future, that ARC has been
discussed and consensus is to consider that topic closed, that's their
purview.  However, such a decision cannot be derived directly from the
charter text I'm looking at.  In particular, this text:

"The DKIM working group will first develop and publish a clear problem
statement.
Then, it will produce one or more technical specifications that propose
replay-resistant mechanisms. The working group will prefer solutions
compatible
with DKIM's broad deployment, and there will be an expectation that these
solutions
will have been through implementation and interoperability testing before
publication."

...does not, to me, constrain the solution space to DKIM itself.  If
there's a solution to DKIM replay outside of DKIM itself, then it's fair
game.

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Dave Crocker]

On 8/4/2023 12:03 PM, Jim Fenton wrote:

The charter calls for a standards-track specification by December. It would 
seem problematic if it has a normative reference to an experimental 
specification.


ahh.  thanks for clarifying.

any number of things might resolve that, but yes, it's good to note the 
issue.


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] Proposals for tolerating mailing list modifications

[Michael Thomas]

On 8/4/23 12:03 PM, Jim Fenton wrote:


The charter calls for a standards-track specification by December. It would 
seem problematic if it has a normative reference to an experimental 
specification. But a call for adoption has not been issued yet, so perhaps this 
is jumping the gun.


Exactly. Any proposed modifications to DKIM should be based on DKIM 
itself. Anything else is off-topic. It's not like you can't propose the 
ARC modifications to DKIM in terms of DKIM itself, though all of those 
modifications have nothing to do with the current charter.


Mike

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Dave Crocker]

On 8/4/2023 11:57 AM, Jim Fenton wrote:

On 4 Aug 2023, at 11:53, Dave Crocker wrote:

On 8/4/2023 11:39 AM, Jim Fenton wrote:

I’m even less clear on draft-chuang-mailing-list-modifications. Does it have to 
do with the currently chartered work




... it will help to hear specifics, rather than your asking a generic question 
that throws a burden of proof back on the document author, without providing 
them any indication what criteria you are applying here or any detail about why 
you think it not relevant.

I was not disagreeing with anything. I was asking a question. That’s all.



Jim, the document has text on the topic.

Constructive dialogue requires engaging with what has already been said.

So, for example, you engaged with my (mis)understanding of your note, 
and you explained that you are not disagreeing.  Fine.


What is needed now is to engage with the substance of the draft, which 
already has text about relevance.


Again, it's fine if you think it insufficient, invalid, or the like, but 
constructive dialogue requires that a question like yours start from the 
substance already provided.



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] Proposals for tolerating mailing list modifications

[Jim Fenton]

On 4 Aug 2023, at 11:57, Dave Crocker wrote:

> On 8/4/2023 11:51 AM, Jim Fenton wrote:
>> I was referring to draft-chuang-replay-resistant-arc-07, not what is 
>> mentioned in the subject line. It refers to RFC 8617 which is experimental, 
>> although it lists it as an informative rather than a normative reference 
>> which I think is incorrect.
>
> You think there is a problem with having a nascent draft specification refer 
> to -- or even rely on -- a published, experimental specification?  Really?
>
> I don't recall that being a problem historically nor against any IETF 
> policies, rules, or the like?  Perhaps you can elaborate on your concerns and 
> the historical basis for them?

The charter calls for a standards-track specification by December. It would 
seem problematic if it has a normative reference to an experimental 
specification. But a call for adoption has not been issued yet, so perhaps this 
is jumping the gun.

-Jim

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Michael Thomas]

That is, to the extent that you disagree about its relevance, it will 
help to hear specifics, rather than your asking a generic question 
that throws a burden of proof back on the document author, without 
providing them any indication what criteria you are applying here or 
any detail about why you think it not relevant.


The burden of proof is always on the document author. As it should be. 
Extraordinary claims, extraordinary evidence, etc.


Mike



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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Jim Fenton]

On 4 Aug 2023, at 11:53, Dave Crocker wrote:

> On 8/4/2023 11:39 AM, Jim Fenton wrote:
>> I’m even less clear on draft-chuang-mailing-list-modifications. Does it have 
>> to do with the currently chartered work
>
>
> DKIM WG charter:
>
>"it will produce one or more technical specifications that propose
>replay-resistant mechanisms."
>
> I don't have an opinion about the quality or utility of this I-D, but it has 
> quite a few references to replay, including:
>
>"The validation results in this specification are orthogonal to the
>results indraft-chuang-replay-resistant-arc
> .
>In addition to better supporting DMARC in the presence of
>mailing-list modifications, this specification enables attribution
>of malicious content back to the author. However this specification
>is vulnerable to replay much like DKIM and ARC.
>draft-chuang-replay-resistant-arc
>
>validation is tolerant of header and message body modifications but
>unable to provide attribution."
>
>
> This would seem to answer you question.  That is, it has text indicating 
> relevance.
>
> You might disagree that it's relevant.  That's fine, but to promote useful 
> discussion, details are needed.
>
> From you.
>
> That is, to the extent that you disagree about its relevance, it will help to 
> hear specifics, rather than your asking a generic question that throws a 
> burden of proof back on the document author, without providing them any 
> indication what criteria you are applying here or any detail about why you 
> think it not relevant.

I was not disagreeing with anything. I was asking a question. That’s all.

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Dave Crocker]

On 8/4/2023 11:51 AM, Jim Fenton wrote:

I was referring to draft-chuang-replay-resistant-arc-07, not what is mentioned 
in the subject line. It refers to RFC 8617 which is experimental, although it 
lists it as an informative rather than a normative reference which I think is 
incorrect.


You think there is a problem with having a nascent draft specification 
refer to -- or even rely on -- a published, experimental specification?  
Really?


I don't recall that being a problem historically nor against any IETF 
policies, rules, or the like?  Perhaps you can elaborate on your 
concerns and the historical basis for them?


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] Proposals for tolerating mailing list modifications

[Dave Crocker]

On 8/4/2023 11:39 AM, Jim Fenton wrote:

I’m even less clear on draft-chuang-mailing-list-modifications. Does it have to 
do with the currently chartered work



DKIM WG charter:

   "it will produce one or more technical specifications that propose
   replay-resistant mechanisms."

I don't have an opinion about the quality or utility of this I-D, but it 
has quite a few references to replay, including:


   "The validation results in this specification are orthogonal to the
   results indraft-chuang-replay-resistant-arc
   .
   In addition to better supporting DMARC in the presence of
   mailing-list modifications, this specification enables attribution
   of malicious content back to the author. However this specification
   is vulnerable to replay much like DKIM and ARC.
   draft-chuang-replay-resistant-arc
   
   validation is tolerant of header and message body modifications but
   unable to provide attribution."


This would seem to answer you question.  That is, it has text indicating 
relevance.


You might disagree that it's relevant.  That's fine, but to promote 
useful discussion, details are needed.


From you.

That is, to the extent that you disagree about its relevance, it will 
help to hear specifics, rather than your asking a generic question that 
throws a burden of proof back on the document author, without providing 
them any indication what criteria you are applying here or any detail 
about why you think it not relevant.


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] Proposals for tolerating mailing list modifications

[Jim Fenton]

On 4 Aug 2023, at 11:43, Dave Crocker wrote:

> On 8/4/2023 11:39 AM, Jim Fenton wrote:
>> concerns about creating a dependency on something experimental
>
>
> I missed the details about a 'dependency'.
>
> What is it that would be dependent and what is it it would be dependent on?

I was referring to draft-chuang-replay-resistant-arc-07, not what is mentioned 
in the subject line. It refers to RFC 8617 which is experimental, although it 
lists it as an informative rather than a normative reference which I think is 
incorrect.

-Jim

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Dave Crocker]

On 8/4/2023 11:39 AM, Jim Fenton wrote:

concerns about creating a dependency on something experimental



I missed the details about a 'dependency'.

What is it that would be dependent and what is it it would be dependent on?

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] Proposals for tolerating mailing list modifications

[Michael Thomas]

On 8/4/23 11:31 AM, Tim Wicinski wrote:


Michael

Actually it appears draft-chuang-replay-resistant-arc is listed in the 
charter (I had to check for myself).
We can have the larger ARC discussion but I'll want to talk to Murray 
and Laura on that also.


And what of the mailing list traversal? That clearly has nothing at all 
to do with the current charter.


DKIM is a full internet standard. ARC is an experiment with no data 
given to show that it does anything that DKIM can't. Any proposal should 
be written in terms of modifications to DKIM itself, not some unproven 
experiment.


Mike



tim


On Fri, Aug 4, 2023 at 2:27 PM Michael Thomas  wrote:


On 8/4/23 11:12 AM, Wei Chuang wrote:
> Hi all,
> I just wanted to mention two proposals for tolerating mailing list
> modifications as suggested in person IETF-117. They both use ARC
> headers as infrastructure, but go about tolerating mailing list
> modifications in different ways.
> 1) Disclose and reverse mailing list transforms so that we can
> authenticate those messages with the original DKIM signature:
>
https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
> 2) Replay-resistant-arc draft proposes authenticating a sender
defined
> path from originating sender to receiver.  It also has the sender
> specify the intended recipient to prevent replay amplification. 
It is
> insensitive to message body modifications:
> https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
> Both approaches do not require trusting results in
> ARC-Authentication-Results which has been a concern. Instead they
> provide signatures and values that a third party can
independently and
> objectively verify.  Discussion of these drafts belong on the DKIM
> list (ietf-dkim@ietf.org). Also just mentioning I've heard there
are
> other interesting related drafts.
>
What does this have to do with the current charter? ARC is
off-topic and
should be banned by the chairs. That is especially true since DKIM
is a
full internet standard and ARC is an experiment with no supporting
data
to show that it's done what it claims.

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] Proposals for tolerating mailing list modifications

[Jim Fenton]

On 4 Aug 2023, at 11:31, Tim Wicinski wrote:

> Michael
>
> Actually it appears  draft-chuang-replay-resistant-arc is listed in the
> charter (I had to check for myself).
> We can have the larger ARC discussion but I'll want to talk to Murray and
> Laura on that also.

Agree with Mike’s concerns about creating a dependency on something 
experimental, but I’m even less clear on 
draft-chuang-mailing-list-modifications. Does it have to do with the currently 
chartered work or was it shared with the list because it relates to DKIM?

-Jim

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Tim Wicinski]

Michael

Actually it appears  draft-chuang-replay-resistant-arc is listed in the
charter (I had to check for myself).
We can have the larger ARC discussion but I'll want to talk to Murray and
Laura on that also.

tim


On Fri, Aug 4, 2023 at 2:27 PM Michael Thomas  wrote:

>
> On 8/4/23 11:12 AM, Wei Chuang wrote:
> > Hi all,
> > I just wanted to mention two proposals for tolerating mailing list
> > modifications as suggested in person IETF-117. They both use ARC
> > headers as infrastructure, but go about tolerating mailing list
> > modifications in different ways.
> > 1) Disclose and reverse mailing list transforms so that we can
> > authenticate those messages with the original DKIM signature:
> >
> https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
> > 2) Replay-resistant-arc draft proposes authenticating a sender defined
> > path from originating sender to receiver.  It also has the sender
> > specify the intended recipient to prevent replay amplification.  It is
> > insensitive to message body modifications:
> > https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
> > Both approaches do not require trusting results in
> > ARC-Authentication-Results which has been a concern.  Instead they
> > provide signatures and values that a third party can independently and
> > objectively verify.  Discussion of these drafts belong on the DKIM
> > list (ietf-dkim@ietf.org).  Also just mentioning I've heard there are
> > other interesting related drafts.
> >
> What does this have to do with the current charter? ARC is off-topic and
> should be banned by the chairs. That is especially true since DKIM is a
> full internet standard and ARC is an experiment with no supporting data
> to show that it's done what it claims.
>
> 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] Proposals for tolerating mailing list modifications

[Michael Thomas]

On 8/4/23 11:12 AM, Wei Chuang wrote:

Hi all,
I just wanted to mention two proposals for tolerating mailing list 
modifications as suggested in person IETF-117. They both use ARC 
headers as infrastructure, but go about tolerating mailing list 
modifications in different ways.
1) Disclose and reverse mailing list transforms so that we can 
authenticate those messages with the original DKIM signature: 
https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
2) Replay-resistant-arc draft proposes authenticating a sender defined 
path from originating sender to receiver.  It also has the sender 
specify the intended recipient to prevent replay amplification.  It is 
insensitive to message body modifications: 
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
Both approaches do not require trusting results in 
ARC-Authentication-Results which has been a concern.  Instead they 
provide signatures and values that a third party can independently and 
objectively verify.  Discussion of these drafts belong on the DKIM 
list (ietf-dkim@ietf.org).  Also just mentioning I've heard there are 
other interesting related drafts.


What does this have to do with the current charter? ARC is off-topic and 
should be banned by the chairs. That is especially true since DKIM is a 
full internet standard and ARC is an experiment with no supporting data 
to show that it's done what it claims.


Mike

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

[Ietf-dkim] Updated Replay Resistant ARC draft -07

[Wei Chuang]

Hi all,
I've updated the I-D draft-chuang-replay-resistant-arc

to -07.  That change does the following:
* Move the SeRCi and Relay ID proposals to the appendix
* Change all the examples use DARA
* Clean up the text now that DARA is the only proposal
* Move the "fh=" tag to the ARC-Message-Signature
* Change the language around Forwarded-to to permit multiple recipients
addresses to be specified

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

[Ietf-dkim] Proposals for tolerating mailing list modifications

[Wei Chuang]

Hi all,
I just wanted to mention two proposals for tolerating mailing list
modifications as suggested in person IETF-117.  They both use ARC headers
as infrastructure, but go about tolerating mailing list modifications in
different ways.
1) Disclose and reverse mailing list transforms so that we can authenticate
those messages with the original DKIM signature:
https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
2) Replay-resistant-arc draft proposes authenticating a sender defined path
from originating sender to receiver.  It also has the sender specify the
intended recipient to prevent replay amplification.  It is insensitive to
message body modifications:
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
Both approaches do not require trusting results in
ARC-Authentication-Results which has been a concern.  Instead they provide
signatures and values that a third party can independently and objectively
verify.  Discussion of these drafts belong on the DKIM list (
ietf-dkim@ietf.org).  Also just mentioning I've heard there are other
interesting related drafts.
-Wei
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim