Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Jim Fenton]

On 25 Mar 2023, at 8:57, Michael Thomas wrote:

> Somebody brought up that this could turn into a research project. Frankly I 
> think that is highly likely the case and is why rechartering was so 
> problematic. Since M3AAWG can't figure it out with lots of inside the 
> industry information, what makes anybody think the wider community would have 
> better insight which is not speculative because it has been tested and known 
> to work? It speaks volumes that they didn't have a solution in mind and bring 
> it to IETF to vet in the wider community. That sure sounds like a research 
> project to me.

It may indeed be a research project, but I’d rather see that happen in IETF or 
some similarly open venue rather than to have it happen in a closed forum like 
M3AAWG, which brings the risk that the proposed solution will meet the needs of 
only the large domains that are M3AAWG members, and not the small ones that 
aren’t.

-Jim

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

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Michael Thomas]

On 3/24/23 6:19 PM, Barry Leiba wrote:

I don't agree with the premise.  I think what was tried and didn't
work should be documented in the result that the working group comes
out with, but not in the problem statement.


There isn't a place in the charter/milestones for that. When I proposed 
that we should do a problem statement, I wasn't expecting it to be a 
bare rehash of what's already in the charter. The current drafts are 
barely more than what's in the charter.


But as I said, we either get this out in the open now, or we'll have to 
get it in the open later. Putting it into the problem statement makes it 
easy to document the failure later instead of adding it to the confusion 
of whether anything can be done. That is, do the fact finding upfront.


Mike



Barry

On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas  wrote:


And yes, that means spam filters and the rest of the ecosystem around
email in which DKIM operates. As in, why exactly are we here? Why can't
industry groups come up with their own solutions? We either document it
now, or argue about it later especially when it becomes plain that there
is no protocol solution and that a BCP is the only possible positive
outcome of this rechartering. An outcome that is specifically allowed
for in the charter I will note. It need not be exhaustive, but it would
be good to document some of the constraints on the solution space as
well as what has been tried and failed. x= is a perfect example.

Also: there has not been any consensus that the shape and scope of the
two current proposals is correct or sufficient. We are far from the
point that this is just wordsmithing imo, appeals to the contrary not
withstanding.

Somebody brought up that this could turn into a research project.
Frankly I think that is highly likely the case and is why rechartering
was so problematic. Since M3AAWG can't figure it out with lots of inside
the industry information, what makes anybody think the wider community
would have better insight which is not speculative because it has been
tested and known to work? It speaks volumes that they didn't have a
solution in mind and bring it to IETF to vet in the wider community.
That sure sounds like a research project to me.

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] What has been tried and doesn't work should be documented in the problem statement

[Barry Leiba]

I don't agree with the premise.  I think what was tried and didn't
work should be documented in the result that the working group comes
out with, but not in the problem statement.

Barry

On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas  wrote:
>
>
> And yes, that means spam filters and the rest of the ecosystem around
> email in which DKIM operates. As in, why exactly are we here? Why can't
> industry groups come up with their own solutions? We either document it
> now, or argue about it later especially when it becomes plain that there
> is no protocol solution and that a BCP is the only possible positive
> outcome of this rechartering. An outcome that is specifically allowed
> for in the charter I will note. It need not be exhaustive, but it would
> be good to document some of the constraints on the solution space as
> well as what has been tried and failed. x= is a perfect example.
>
> Also: there has not been any consensus that the shape and scope of the
> two current proposals is correct or sufficient. We are far from the
> point that this is just wordsmithing imo, appeals to the contrary not
> withstanding.
>
> Somebody brought up that this could turn into a research project.
> Frankly I think that is highly likely the case and is why rechartering
> was so problematic. Since M3AAWG can't figure it out with lots of inside
> the industry information, what makes anybody think the wider community
> would have better insight which is not speculative because it has been
> tested and known to work? It speaks volumes that they didn't have a
> solution in mind and bring it to IETF to vet in the wider community.
> That sure sounds like a research project to me.
>
> 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

[Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Michael Thomas]

And yes, that means spam filters and the rest of the ecosystem around 
email in which DKIM operates. As in, why exactly are we here? Why can't 
industry groups come up with their own solutions? We either document it 
now, or argue about it later especially when it becomes plain that there 
is no protocol solution and that a BCP is the only possible positive 
outcome of this rechartering. An outcome that is specifically allowed 
for in the charter I will note. It need not be exhaustive, but it would 
be good to document some of the constraints on the solution space as 
well as what has been tried and failed. x= is a perfect example.


Also: there has not been any consensus that the shape and scope of the 
two current proposals is correct or sufficient. We are far from the 
point that this is just wordsmithing imo, appeals to the contrary not 
withstanding.


Somebody brought up that this could turn into a research project. 
Frankly I think that is highly likely the case and is why rechartering 
was so problematic. Since M3AAWG can't figure it out with lots of inside 
the industry information, what makes anybody think the wider community 
would have better insight which is not speculative because it has been 
tested and known to work? It speaks volumes that they didn't have a 
solution in mind and bring it to IETF to vet in the wider community. 
That sure sounds like a research project to me.


Mike

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

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Laura Atkins]

> On 24 Mar 2023, at 18:14, Scott Kitterman  wrote:
> 
> 
> 
> On March 24, 2023 5:42:41 PM UTC, Michael Thomas  wrote:
>> 
>> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:
>>> 
>>> 
>>> Fine with me, it's far from a showstopper overall.  I just made the 
>>> suggestion.
>>> 
>> This wg should be concerned with DKIM problems, not other wg problems and 
>> especially for experimental rfc's of dubious value and complete mysteries as 
>> to what they have to do with their actual charter.
> 
> As long as you include integration of DKIM into the overall email 
> architecture and broader impacts of DKIM changes as part of 'concerned with 
> DKIM problems', I agree.

I agree with this. We do, I think, need to acknowledge that DKIM is part of a 
complicated landscape of authentication protocols that are independent and 
interdependent. 

laura (participating) 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Hector Santos]

+1.

ARC is not a solution, but it is a good part of the problem. It’s not hard to 
see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model 
in lieu of Reputation Modeling creating this issue.

Every issue we have today is nearly 100% because of the lob-sided efforts to 
impose a DKIM Reputation Model on receivers when it was predicted during MARID 
and into early DKIM that if we do this, we will have issues related to the 
"Batteries Required" Syndrome.

- No standard Reputation Protocol
- No single repository of GOOD vs BAD domains
- To be somewhat effective, Batteries Requires (paid 3rd party service)
- Exploiters attacking those without Batteries.

This is why the original DKIM Charter tried really hard to focus on 
Deterministic Protocols rather than Heuristic Protocols based on the Author 
Domain. The original DKIM Charter considered “Reputation Modeling” out of scope.

Now it is in scope and we are dealing with issues that can not be solved — not 
without addressing the DKIM Policy Model for 1st and 3rd party signers.

If the group effort is to be able to write a PS for DKIM + Reputation Modeling, 
we should highly note it was all perpetuated by our defocus of DKIM Policy 
Modeling and the lack of will to fix DMARC.


—
HLS

> On Mar 24, 2023, at 1:42 PM, Michael Thomas  wrote:
> 
> 
> 
> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:
>> 
>> 
>> Fine with me, it's far from a showstopper overall.  I just made the 
>> suggestion.
>> 
> This wg should be concerned with DKIM problems, not other wg problems and 
> especially for experimental rfc's of dubious value and complete mysteries as 
> to what they have to do with their actual charter.
> 
> 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] Comments on draft-chuang-dkim-replay-problem

[Scott Kitterman]

On March 24, 2023 5:42:41 PM UTC, Michael Thomas  wrote:
>
>On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:
>> 
>> 
>> Fine with me, it's far from a showstopper overall.  I just made the 
>> suggestion.
>> 
>This wg should be concerned with DKIM problems, not other wg problems and 
>especially for experimental rfc's of dubious value and complete mysteries as 
>to what they have to do with their actual charter.

As long as you include integration of DKIM into the overall email architecture 
and broader impacts of DKIM changes as part of 'concerned with DKIM problems', 
I agree.

Scott K

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

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Michael Thomas]

On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:



Fine with me, it's far from a showstopper overall.  I just made the 
suggestion.


This wg should be concerned with DKIM problems, not other wg problems 
and especially for experimental rfc's of dubious value and complete 
mysteries as to what they have to do with their actual charter.


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

Re: [Ietf-dkim] Problem statement adoption

[Dave Crocker]

On 3/24/2023 6:45 AM, Dave Crocker wrote:

On 3/24/2023 6:42 AM, Laura Atkins wrote:
We currently have two problem statements to discuss for adoption. 
Wei is merging 'mine' into his.  (Note mine was done as a variant of 
his.) 



For folks new to IETF processes, it might be worth explaining that 
contributions about an existing draft are usually anchored in specific 
suggestions for adding/changing/removing text.  This ensures that a) 
whatever concern is being raised is clearly linked to a specific part of 
the draft, and b) provides concrete, candidate text to evaluate.  This 
quite reliably develops movement towards document completion.


Sometimes, this process does not converge to the satisfaction of one or 
another participant.  Their usual response, then, is what I did: I wrote 
an alternative.  In my case it was explicitly derivative, with a goal of 
getting either chosen or merged.  In other cases, it might be completely 
independent.


Working groups often get bogged down debating concepts.  Having concrete 
text to review, debate, and decide about tends to mitigate against the 
infinite delay that staying at too high a level often produces.


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] Comments on draft-chuang-dkim-replay-problem

[Murray S. Kucherawy]

On Fri, Mar 24, 2023 at 9:59 AM Dave Crocker  wrote:

> On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote:
> > I think I concur with the suggestion that wa should drop discussion of
> > ARC.  This WG, or the DMARC WG, can develop an update to ARC based on
> > the outcome here if the community chooses to do so, but I don't think
> > it should be part of this WG's premise.
>
> sigh.  The draft only makes a quick, careful reference to ARC's having a
> similar vulnerability.  Given it's underlying similarity to DKIM and
> given that this is an introductory document rather than a specification,
> I think it appropriate to give the reader a heads up.  (FWIW, for early
> versions of the draft I was also inclined to want it out.  I think the
> current, brief text is, however, apt.)
>

Fine with me, it's far from a showstopper overall.  I just made the
suggestion.


> > Section 1.2:
> >
> > The opening sentence that emphasizes non-use of RFC 2119, amusingly,
> > forces you to include a reference to RFC 2119.  I suggest instead:
> > "This document is not normative in any way."
>
> As I recall, there was some discussion about this.  For one thing, the
> IETF really likes seeing the reference.  Including it ensures no hiccups
> in the mechanics of handling the document. (And, yes, it is amusing.)
>

I've seen at least the current IESG encourage removal of the reference when
it's not really needed.  It's harmless to leave it in, I suppose, but I'd
be unsurprised to get the question again during IESG Evaluation.


> > Section 6 can simply say there are no security considerations for a
> > problem statement document, though you anticipate some interesting
> > ones in documents to follow.  :-)
>
> Hmmm.  On the other hand, have some discussion of security-related
> issues in a section identified for that topic, might be useful for
> highlighting dangers or concerns.
>

I've always thought of Security Considerations as a place to hold a
discussion about what security issues are being introduced by the material
in the document.  I don't think any are or will be here, which was the
point I was making.  Those would come in any follow-on protocol or best
practices work.

Then again, I don't think anyone's going to complain if we do have an
informative security discussion.  So, as before, just a suggestion.

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

Re: [Ietf-dkim] Problem statement adoption

[Michael Thomas]

Neither in their current forms. They are far too vague. They don't 
specify what has been tried and/or are not adequate or don't work. They 
should not be considered as the only two options.


Also: potential BCP's are in scope via the charter. That requires way 
more information than any supposed protocol solution. Since that is by 
far the most likely output of this, dismissing any talk of them is 
violating the stated charter.


Mike

On 3/24/23 6:42 AM, Laura Atkins wrote:

We currently have two problem statements to discuss for adoption.

In order to move the adoption forward can we get some specific 
consensus on the drafts that we currently have on the table or some 
specific wording changes needed before adoption.


The drafts on the table:

Draft 1: 
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/


Draft 2: https://datatracker.ietf.org/doc/draft-crocker-dkim-replay/

Questions to answer:

Should we adopt Draft 1?

Should we adopt Draft 2?

Alternatively:

Should we take Draft 1 or Draft 2 and edit or modify it to reflect the 
consensus of the group?


Do we have any volunteers to handle editing duties?

laura


--
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Email Delivery Blog: http://wordtothewise.com/blog







___
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] Clarifying the problem

[Michael Thomas]

On 3/24/23 9:58 AM, Laura Atkins wrote:




On 24 Mar 2023, at 16:48, Michael Thomas  wrote:


On 3/24/23 6:14 AM, Laura Atkins wrote:
Please, let’s focus on the current issue with is addressing  and 
refining the problem statement.


So you agree with me that any discussion of ARC and its complete 
failings should be out of scope? I would appreciate the chairs 
enforcing that.


I said we should be focusing on addressing and refining the problem 
statement.


Maybe you should have a conversation with your AD who brought up ARC in 
one of the threads here.


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

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Dave Crocker]

Murray,

I'll skip over comments that I think will be resolved as Wei 
incorporates my text or that I don't have a useful comment on...


On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote:
I think I concur with the suggestion that wa should drop discussion of 
ARC.  This WG, or the DMARC WG, can develop an update to ARC based on 
the outcome here if the community chooses to do so, but I don't think 
it should be part of this WG's premise.


sigh.  The draft only makes a quick, careful reference to ARC's having a 
similar vulnerability.  Given it's underlying similarity to DKIM and 
given that this is an introductory document rather than a specification, 
I think it appropriate to give the reader a heads up.  (FWIW, for early 
versions of the draft I was also inclined to want it out.  I think the 
current, brief text is, however, apt.)




Section 1.2:

The opening sentence that emphasizes non-use of RFC 2119, amusingly, 
forces you to include a reference to RFC 2119.  I suggest instead: 
"This document is not normative in any way."


As I recall, there was some discussion about this.  For one thing, the 
IETF really likes seeing the reference.  Including it ensures no hiccups 
in the mechanics of handling the document. (And, yes, it is amusing.)



Are we sure SPF and DMARC should be in scope for this work?  SPF feels 
irrelevant, and DMARC feels like a layer violation.  If we want to do 
so, we could refer the reader to the RFCs defining those protocols 
just to make them aware of the bits of the ecosystem, but then I would 
leave them out of the rest of the document.



Section 6 can simply say there are no security considerations for a 
problem statement document, though you anticipate some interesting 
ones in documents to follow.  :-)


Hmmm.  On the other hand, have some discussion of security-related 
issues in a section identified for that topic, might be useful for 
highlighting dangers or concerns.


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] Clarifying the problem

[Laura Atkins]

> On 24 Mar 2023, at 16:48, Michael Thomas  wrote:
> 
> 
> On 3/24/23 6:14 AM, Laura Atkins wrote:
>> Please, let’s focus on the current issue with is addressing  and refining 
>> the problem statement.
> 
> So you agree with me that any discussion of ARC and its complete failings 
> should be out of scope? I would appreciate the chairs enforcing that.

I said we should be focusing on addressing and refining the problem statement. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] Process Questions

[Michael Thomas]

On 3/24/23 6:15 AM, Laura Atkins wrote:





On 10 Mar 2023, at 00:30, Michael Thomas 
 wrote:

Now that we have a chair, I have a question about process wrt
to the charter. The charter states that either the working
group will produce documents addressing the problem, or it will
produce a document saying why it can't do anything about it
within the IETF confines. I strongly suspect that that the
latter will be the conclusion but I don't know what the process
would look like to come to that conclusion. It seems like it
entails a long list of "can't do this"'s etc followed by "we
give up". But that list could be nearly endless if it is
allowed to get out of hand. So what does it take to come to
that conclusion from a process standpoint?


Our current milestones are:

Apr 2023 - Post a consensus problem statement draft to the
datatracker (may
 not go to the IESG)

 Jun 2023 - Proposal regarding plans for remaining document(s)
presented to
 the AD

 Dec 2023 - Submit technical specifications for replay-resistant
DKIM
 enhancement(s) to the IESG at Proposed Standard



Per the charter, Or Not. That is what I'm asking about.


Between the milestones and the charter text, the charter text is 
typically the more important of the two.  Milestones can be edited 
without full IESG review, while the charter can't.  So if the working 
group needs more time than April or June, that can be negotiated.


I’d like to get a problem statement done by April. What I’m seeing is 
a lot of people focused on solutions or having side discussions about 
spam filters rather than looking at the wording of the two proposed 
problem statements we have on the table.


As I've said, the two proposed problem statements are far too vague. 
It's not about wordsmithing them. It's about having something that 
actually discusses what is known about the problem.


And BTW: the charter says that a BCP is in scope. That is not a "side 
discussion".


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

Re: [Ietf-dkim] Clarifying the problem

[Michael Thomas]

On 3/24/23 6:14 AM, Laura Atkins wrote:
Please, let’s focus on the current issue with is addressing  and 
refining the problem statement.


So you agree with me that any discussion of ARC and its complete 
failings should be out of scope? I would appreciate the chairs enforcing 
that.


Mike

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

[Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Murray S. Kucherawy]

Informal comments only here.  I know a merger with Dave's draft is in
progress, so some of these may not apply by the time you're done.

Section 1.1:

It feels a little presumptuous to assume any DKIM receiver has also built
out a reputation system, or has access to one.  I guess it might depend on
what you consider a reputation system though; are there DNSxLs for DKIM
domains that are open to the public?  I don't think SpamAssassin carries
with it a set of domains that should be dropped if they carry valid DKIM
signatures.  Either way, I think the generalization is peculiar.  At a
minimum, say "some systems develop reputations" etc.

I think I concur with the suggestion that wa should drop discussion of
ARC.  This WG, or the DMARC WG, can develop an update to ARC based on the
outcome here if the community chooses to do so, but I don't think it should
be part of this WG's premise.

Section 1.2:

The opening sentence that emphasizes non-use of RFC 2119, amusingly, forces
you to include a reference to RFC 2119.  I suggest instead: "This document
is not normative in any way."

"administratively" should be "administrative functions" or similar.
("users" and "services" are nouns, so this should be too.)S

The "List-*" header fields are defined in RFC 4021.

In "trace and operational headers", "headers" should be "header fields".

Are we actually defining new Mail Handling Services here, or rather
declaring special cases of Originators and Relays?  Do they become Authors
again after they've handled/filtered a message?

Are we sure SPF and DMARC should be in scope for this work?  SPF feels
irrelevant, and DMARC feels like a layer violation.  If we want to do so,
we could refer the reader to the RFCs defining those protocols just to make
them aware of the bits of the ecosystem, but then I would leave them out of
the rest of the document.

Section 2:

"headers" should be "header fields"

"customized by" the ultimate recipient?  or should that be "for"?

Involvement of SPF here doesn't seem to be needed either.  We only need to
tall the DKIM story.
I think the notion of folders also exceeds DKIM's scope.  That's a handling
choice post-DKIM.  It's enough to highlight that a false positive is
procured by the attacker, to the attacker's benefit.

Section 3:

Does including SPF in this part of the discussion contribute to the problem
statement or muddy it?  This is about DKIM, not about spam handling in
general.

Section 3.1's "DKIM" bullet talks about signature survival, while Section
3.2's "DKIM" bullet talks about who does the signing.  This seems
dissonant, or at least makes them hard to compare and contrast since they
talk about different things.

Section 4:

Caching known signatures, a con: adds a potentially expensive database
component to the receiving service, and will require tinkering to figure
out what cache duration is appropriate to catch replays while not also
catching legitimate mail.

The "sign for the next hop" proposal could use a language tweak of some
kind.  I can't quite put my finger on it.  If it's "sign for the next hop"
at a host level, I have to know that host; today, I just sign and toss it
in the queue, and my MTA figures out which MX is going to take it, but if I
have to know which MX that is, I can't sign until connection time;
milter-based filters at least don't work that way because the integration
point doesn't allow it.  If it's actually "sign for the next ADMD", that
problem goes away, but the definition of "ADMD" gets a bit muddy because
now you have to include in that definition any MX that might be providing
transparent store-and-forward.

Section 5 you won't need.

Section 6 can simply say there are no security considerations for a problem
statement document, though you anticipate some interesting ones in
documents to follow.  :-)

Lastly, you can drop the "yet" from Section 7.  :-)

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

Re: [Ietf-dkim] Problem statement adoption

[Laura Atkins]

Great! Thanks.

laura 



> On 24 Mar 2023, at 14:14, Wei Chuang  wrote:
> 
> +1 I'm working on it.
> 
> -wei
> 
> On Fri, Mar 24, 2023, 6:45 AM Dave Crocker  > wrote:
>> On 3/24/2023 6:42 AM, Laura Atkins wrote:
>> > We currently have two problem statements to discuss for adoption. 
>> 
>> Wei is merging 'mine' into his.  (Note mine was done as a variant of his.)
>> 
>> I believe there will again be only one draft.
>> 
>> 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

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] Problem statement adoption

[Wei Chuang]

+1 I'm working on it.

-wei

On Fri, Mar 24, 2023, 6:45 AM Dave Crocker  wrote:

> On 3/24/2023 6:42 AM, Laura Atkins wrote:
> > We currently have two problem statements to discuss for adoption.
>
> Wei is merging 'mine' into his.  (Note mine was done as a variant of his.)
>
> I believe there will again be only one draft.
>
> 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
>


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] Problem statement adoption

[Dave Crocker]

On 3/24/2023 6:42 AM, Laura Atkins wrote:
We currently have two problem statements to discuss for adoption. 


Wei is merging 'mine' into his.  (Note mine was done as a variant of his.)

I believe there will again be only one draft.

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

[Ietf-dkim] Problem statement adoption

[Laura Atkins]

We currently have two problem statements to discuss for adoption. 

In order to move the adoption forward can we get some specific consensus on the 
drafts that we currently have on the table or some specific wording changes 
needed before adoption. 

The drafts on the table: 

Draft 1: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/

Draft 2: https://datatracker.ietf.org/doc/draft-crocker-dkim-replay/ 

Questions to answer: 

Should we adopt Draft 1? 

Should we adopt Draft 2?

Alternatively: 

Should we take Draft 1 or Draft 2 and edit or modify it to reflect the 
consensus of the group?

Do we have any volunteers to handle editing duties?

laura 


-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] Process Questions

[Laura Atkins]

>>> 
 On 10 Mar 2023, at 00:30, Michael Thomas  
  wrote:
 
 Now that we have a chair, I have a question about process wrt to the 
 charter. The charter states that either the working group will produce 
 documents addressing the problem, or it will produce a document saying why 
 it can't do anything about it within the IETF confines. I strongly suspect 
 that that the latter will be the conclusion but I don't know what the 
 process would look like to come to that conclusion. It seems like it 
 entails a long list of "can't do this"'s etc followed by "we give up". But 
 that list could be nearly endless if it is allowed to get out of hand. So 
 what does it take to come to that conclusion from a process standpoint?
>>> 
>>> Our current milestones are:
>>> 
>>> Apr 2023 - Post a consensus problem statement draft to the datatracker (may
>>>  not go to the IESG)
>>> 
>>>  Jun 2023 - Proposal regarding plans for remaining document(s) presented to
>>>  the AD
>>> 
>>>  Dec 2023 - Submit technical specifications for replay-resistant DKIM
>>>  enhancement(s) to the IESG at Proposed Standard
>> 
>> Per the charter, Or Not. That is what I'm asking about.
>> 
> 
> Between the milestones and the charter text, the charter text is typically 
> the more important of the two.  Milestones can be edited without full IESG 
> review, while the charter can't.  So if the working group needs more time 
> than April or June, that can be negotiated.

I’d like to get a problem statement done by April. What I’m seeing is a lot of 
people focused on solutions or having side discussions about spam filters 
rather than looking at the wording of the two proposed problem statements we 
have on the table. 

> Plus, frankly, I made up those dates during chartering.  The chairs and I 
> haven't discussed whether they're reasonable or whether something else should 
> be there.  If people want to propose adjustments, I'm all ears.

I do want to stick with April for the problem statement. It should be a 
deadline we can meet with a little bit of focus on defining the problem 
statement. 

laura 




> 
> -MSK, this time with the AD hat on
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [Ietf-dkim] Clarifying the problem

[Laura Atkins]

Please, let’s focus on the current issue with is addressing  and refining the 
problem statement. 

laura 


> On 23 Mar 2023, at 20:27, Michael Thomas  wrote:
> 
> 
> On 3/23/23 2:52 AM, Alessandro Vesely wrote:
>> On Wed 22/Mar/2023 20:31:51 +0100 Michael Thomas wrote:
>>> On 3/21/23 8:01 PM, Murray S. Kucherawy wrote:
>>> 
>  1. What percent of incoming email to a mailbox is through
> resenders and of that what percent resign?
 
 By "resign" you mean something that has signatures from two domains, 
 correct?  If so, how could one tell whether the originating operator did 
 or did not attach one or more of them?
>>> 
>>> As in a mailing list makes a breaking change but resigns it with its own 
>>> domain. The mailing could obviously sign their auth-res which if they have 
>>> a good reputation the receiver might trust as a reasonable proxy.
>> 
>> 
>> That's reinventing ARC!
> 
> No, ARC is reinventing DKIM. Needlessly.
> 
> 
>> 
>> I too used to be very skeptic about ARC (mainly because of the conjectured 
>> assumption that ARC sealers can be trusted based on an available reputation 
>> database, which skews usability toward global providers).  I changed my mind.
>> 
>> As a special flavor of DKIM designed around forwarding, ARC can bring real 
>> means to solving this problem.  Indeed, signing or sealing the messages to 
>> be forwarded can uncover the intent and the maker of the forwarding.
>> 
> I have yet to see anything that convinces me that ARC brings anything new and 
> useful to the table. After much hand waving when I was trying to figure out 
> what ARC was about, John Levine finally said that it all boils down to 
> reputation. Well, guess what. The same goes from DKIM for both originators 
> and intermediaries. There has always been the ability to build reputation 
> regardless of the domain doing the signing. This re-chartering of the DKIM wg 
> wouldn't be happening if that were not true. There seems to be an awful lot 
> of magical thinking going on with it.
> 
> Mike
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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